0

I would like to assess the actual risk for various CORS attacks when a web application properly sets CSP and other response headers, but the app server error page does not. When a 40x can be provoked by trying to access protected content, for example, can the error response be used to inject malicious scripts, even though the web application is protected? I just can't envision a scenario where this is done.

Or x-content-type-options: nosniff. It is missing from a 400 error page. Is this a real vulnerability? What can an attacker do with the error response?

Improve this question

1 Answer 1

Reset to default
1

What's on the error page? For Apache Tomcat, it typically contains the requested URL, type of the error message, a human readable description of the error and Tomcat version information.

Apache Tomcat 404 Not Found example

  • The error page itself isn't really vulnerable to cross-origin resource sharing (CORS) attacks, and it's not running anything from the actual application.

  • The X-Content-Type-Options: nosniff prevents the browser from handling non-executable MIME types as executable MIME types. Doesn't really cause harm if a browser tries to execute the error page.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .