Marcel Boeing

Security considerations regarding the Akamai debug HTTP headers

Blog Post created by Marcel Boeing on Jan 28, 2016

Anyone who ever got in touch with the technical side of Akamai Web Performance Products knows about the HTTP debug headers that provide a wealth of useful information about the inner workings behind the Edge response they accompany. With them, you can debug TTL settings, review the Cache ID, check EdgeScape country detection outcome, etc. etc. — without them, you are practically blind by comparison.¹


Of course, all this insight can also be used for malicious purposes, most notably a hypothetical attacker could have a much easier time finding effective attack vectors for a planned DoS — which without, he or she might not be able to do in the first place.


Okay, so there may be risk in the debug information being publicly retrievable, but how risky are we talking? Let's discuss a few examples.


X-Cache-Key and X-True-Cache-Key : This is basically a no-brainer, because the cache key does include the TTL of the requested content (a DoS targeting uncacheable content might overwhelm the origin in spite of Akamai standing in between) and could even disclose the origin hostname if the default "Cache Key Hostname" setting has not been changed (thus enabling an attacker to bypass Akamai completely, unless SiteShield is used).


X-Akamai-Session-Info : The most abundant source of information is found within this response header, because it comes in multiple instances, like "X-Akamai-Session-Info: name=AKA_PM_TD_ENABLED; value=false" which tells you (along with X-Cache-Remote) whether Tiered Distribution is used, or "X-Akamai-Session-Info: name=EDGECONNECT_ENDPOINT_HOST;", broadening our visible attack surface by revealing a further potential target's hostname.


"X-Akamai-Session-Info: name=AKA_PM_PREFETCH_ON; value=false" provides another interesting piece of information. With Prefetching enabled, a single request to an HTML page can have the Edge reach back to the origin for the content that is linked to within — if that content is not cacheable it could even (in a manner of speaking) leverage an attack targeted at overwhelming the origin. It might be a bit far-fetched, but illustrates the sheer abundance of new attack vectors that open up with the availability of the respective debug information.


Of course Akamai has top-notch security products that protect the customer origin (like SiteShield) and filter requests detected as being malicious (with Kona's Web Application Firewall). But with the debug headers active and available, one takes away at least some of the effectiveness of those products: For example "X-Akamai-Session-Info: name=WAF_CRS_TOTAL_ANOMALY_SCORE; value=0" lets an attacker know exactly just how much suspicion the last request rose, allowing him or her to adjust the attack accordingly.


Luckily, the obvious solution is neither complex nor expensive in any way. However, deactivating the debug headers altogether would make it impossible for entitled administrators to do all the important and vital things the debug headers are meant for. A practicable way to enhance security while keeping the raise in complexity at a minimum could be, for example, to define a rule checking whether a secret header or cookie (kept confidential) is present within an incoming request, otherwise removing its Pragma header. This simple measure would already make it much less easy for any unauthorized person to gather debug information about your site.


Of course, there are more and better ways to secure the output of debug headers, but the important part is to be aware of their existence (and the security implications) in the first place.



¹ If you are not yet familiar with the Akamai debug headers (and their invocation via Pragma header), do check out this post for an excellent overview to get you started.