Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Cacheable HTTPS Response

Rob | Last updated: Aug 05, 2015 08:32AM UTC

Burp scanner reports that certain pages have a "Cacheable HTTPS Response". However, upon closer inspection it appears that these items are POST requests and the issue is reported because caching headers are missing rather than an explicit cache preference being set. The post here http://stackoverflow.com/q/626057/413180 indicates that POST is only cached by browsers if explicitely told to. The RFC states: "Responses to POST method are not cacheable, UNLESS the response includes appropriate Cache-Control or Expires header fields." For the items reported by BurpSuite there were no Cache-Control or Expires headers in the response from the POST request. Is this a bug?

PortSwigger Agent | Last updated: Aug 10, 2015 09:16AM UTC

We are aware of some defects in Burp's logic when reporting cacheable HTTPS responses, including the fact that responses from GET and POST requests are handled differently by browsers. So yes, this is a bug of sorts. It is in our near-term roadmap to revisit this issue and fix the logic to match the behavior of modern browsers.

PortSwigger Agent | Last updated: Feb 19, 2016 09:48AM UTC

Thanks. We'll investigate this and other issues with the caching scan check.

Burp User | Last updated: Jul 07, 2016 09:36PM UTC

Also, hopefully this is an effective way to disclose/report to the Burp team. I noticed that Burp missed a typo in a response header. It did not notice the wrong header of 'no-cache, no-cache', instead of the proper 'no-cache, no-store'.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.