Using HTTP headers to debug live sites
Tags: webdev, security
Published: 2020-08-27 10:45:07

## TL;DR
You can use a browser extension to send a particular header to your server that will trigger a debug action.

## The facts
![I don't always debug, but when I do, do it in production ](https://dev-to-uploads.s3.amazonaws.com/i/vameexuzwlvuwnoygdrz.jpeg)

Ok, we all know that by the time our code gets to the production server(s) it's free of bugs and will work flawlessly, _right_? 

Oh... we wish! The truth is that all of us, sooner or later, will face a bug that only happens in production. How can we approach this while keeping most of our sanity intact?

## In production you'll never walk alone
In our dev environment we can turn on all debug and logging artillery because we are usually the only user on the site, so all logs show the results of our actions. Be it the web server log, your CGI language error log, [the Maurina console](https://maurina.org) or any other way you have to track what your server code is doing, that info is limited to what you do on the site.

Of course, that's not true in your production site. Many other users are online, generating file requests and API calls and making your logs go all FUBAR (Filled Up Beyond All Recognition). They no longer provide useful info and in high traffic sites eat valuable disk space, so you should turn all debug logging off.

![FUBAR word over soldier's face](https://dev-to-uploads.s3.amazonaws.com/i/xpxfe52ml1btg769x0ts.gif)
<figcaption>Matt Damon really hates debugging live sites</figcaption>

## Solution #1: restrict by IP
The easiest way to achieve this is to execute your debug code only when the request comes from an _authorized_ IP. You can keep a file on disk (preferred) or a variable in your code with a list of IPs and check the request IP against it. A file on disk is better since adding / removing IPs do not imply a code change and a deployment.

While this works, it has some disadvantages:

1. Adding / removing IPs means accessing and editing a file on your live server, and those are very high risk actions that should be avoided or you may end up with your server going _the other_ FUBAR.

2. I, for one, do not have an static IP at home where I work. This means that my IP changes from time to time, sometimes every two days. Editing the IPs file every two days is just too much risk.

So let's finally get to the point of this article:

## Solution #2: use HTTP headers
This solutions requires a browser extension that allows you to edit HTTP headers. I use [ModHeader](chrome.google.com/webstore/detail/modheader/idgpnmonknjnojddfkpgkljpfnnfcklj).

Once installed, you define a header name and its value, and a list of filters that tell the extension which domains should receive this header. This is important, since you don't want to send your custom header name and secret value to any site that is not yours.

This is a screenshot of my ModHeader profile:

![Sample ModHeader profile](https://dev-to-uploads.s3.amazonaws.com/i/lpdqldgjwktkofunk2yb.png)

As you can see I have it enabled for local domains (the ones starting with http) and disabled for live domains (those starting with https). The checkboxes allow you to easily enable / disable sites.

When I need to debug a live (or dev) site the extension adds the header _X-Maurina-Debug_ with a secret value and that tells my server code to enable the Maurina debug code.

_Shameless promo: this Maurina thingy that keeps popping up is a little free and open source program I wrote to help me debug server side code. It's just an UDP server that outputs the data your server sends in four tabs: debug messages generated from source code, error messages, HTTP request data and session information. This is the [website](https://maurina.org) and the [GitHub repo](https://github.com/koas/maurina/)._

The biggest advantage of this method is that adding a new "debug user" doesn't require any server file or code modification. This is also its main disadvantage, since to remove a user or update the secret you must:

* Edit the server file to change the secret value (this is the dangerous part)
* Change the secret value on all the other developer's extensions. This on the other hand is really easy, especially if you are the only developer of your team.

## Beyond debugging
This technique may be used not only for debugging, but also for easy QA testing. For example let's say you're working on an e-learning site where students can take tests. The site is about economy, and you already have an initial set of questions. You don't know a word about economy but want to test when the user passes or fails the test.
    
To solve this you can make your server side code look for an specific header and add something to the correct answer that allows you to spot them and score a 100 without knowing what a stock is.

Once you have this technique under your belt you may find other uses for it, please share them here!

Thanks for reading and happy coding!