Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Security Headers for POST response

Karthik | Last updated: Sep 28, 2015 01:54PM UTC

Hello, I noticed a few POST response (whether 200 or 302) is not having a XSS protection/ Content sniffing / Click Jacking prevention header set and burp suite detected that as a vulnerability. Is there a specific reason why a few POST responses are not having these headers set ? Is this not required ? This is not directly related to Burp Suite functioning, but just wanted to check here. Similarly, there are a few other POST response (200 or 302 status code) is not having X-Frame header set and still Burp did not detect that. Is there any reason behind this ?

PortSwigger Agent | Last updated: Sep 28, 2015 02:15PM UTC

If the application behaves differently on different URLs, in terms of what security-related headers are returned, this could be an oversight or misconfiguration, or it could be deliberate if there is some unusual feature that needs to be supported for those URLs. Burp only reports missing X-Frame-Options header if the response is HTML and contains links. This might account for the differences you observed.

Burp User | Last updated: Sep 29, 2015 07:58AM UTC

Hi Dafydd, Thanks for the clarification. Does the above answer (for missing xss protection/content sniffing headers) apply for 302 redirect responses as well ?

PortSwigger Agent | Last updated: Sep 29, 2015 08:06AM UTC

Burp won't report a missing X-Frame-Options header on 3xx responses. Burp does report X-XSS-Protection: 0 on all responses regardless of status code. Burp doesn't natively report sniffable content as an issue. There are some extensions in the BApp Store that report this.

Burp User | Last updated: Sep 29, 2015 09:21AM UTC

Thanks Dave. Just a quick question Isn't these security headers (X-XSS Protection, Content sniffing, Clickjacking prevention headers) important on 302 responses ? Even if these headers aren't present on a 302 response, doesn't it pose a threat ?

PortSwigger Agent | Last updated: Sep 29, 2015 09:35AM UTC

To repeat, Burp Scanner's native logic only looks at the status code header for the X-Frame-Options issue. If a response is a 302 redirection, then as far as I'm aware the absence of an X-Frame-Options header isn't in itself a vulnerability, because the browser won't actually display the response and will just follow the redirection. When the ultimate redirection target is fetched (normally 200), the browser will prevent framing based on any X-Frame-Options header in that response, and if that header is missing then Burp will report the issue in the normal way.

Burp User | Last updated: Sep 29, 2015 11:21AM UTC

Dafydd, Thanks for the clarification.

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