BIGFOOT IS REAL! And So Is The Need For HTTP Response Security Headers

I got your attention, didn’t I?

HTTP response security headers are a fundamental part of website security and are easy to implement too! As a subset of HTTP headers, they are exchanged explicitly between a client and a server to specify security details for HTTP communication. They can help prevent modern browsers from easily falling prey to preventable vulnerabilities and protect against common attacks, such as cross-site scripting (XSS), clickjacking, information disclosure, code injection, and other vulnerabilities, if implemented appropriately.

HTTP headers are typically invisible to the end-user. Only the client and server applications process and log. However, I’m sure you’ve heard it before... an HTTP Response Security Header can significantly impact web performance, security, and functionality, and is not exactly a popular feature to develop. Shots fired!

Here are a few used in everyday practice and not meant to be an all-inclusive list:

Content-Security-Policy (CSP) helps protect websites and applications against cross-site scripting (XSS) and other attacks by controlling content sources and parameters (filtering out web content sources that are not allowed).

X-Frame Options helps protect against click-jacking and cross-site scripting attacks involving HTML iframes and the page being loaded into the iframe.

X-Content-Type-Options helps protect from cross-site scripting attacks that abuse MIME sniffing.

Referrer-Policy helps control how much referrer information is revealed as it may affect user privacy and put sensitive information on the site at risk.

Cache-Control helps protect against the retention of confidential data and prevents storage in caches via this type of security header.

Clear-Site Data helps ensure that the browser does not store browsing data (confidential information) from the application.

There must be a balance between usability and security! The good news is that it can be added at the software level in just about every web language, and many web frameworks automatically add headers.

Woot!

Here are two:

.net / NWebsec (https://docs.nwebsec.com/en/latest/ )

OwaspHeaders.Core (https://github.com/GaProgMan/OwaspHeaders.Core )

There are also some tools you can use to analyze security headers al-

ready in place, such as:

SecurityHeaders.com

Humble (https://github.com/rfc-st/humble )

Hsecscan (https://github.com/riramar/hsecscan )

To learn more about HTTP Response Security Headers, you can read more about it here: https://

owasp.org/www-project-secure-headers/

This OWASP Cheat Sheet outlines best practices for configuring headers effectively, removing headers to prevent XSS exposure, and more. https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html

https://medium.com/@jencracchiola/bigfoot-is-real-and-so-is-the-need-for-http-response-security-headers-e65333985e6f?sk=795b6ec5954df807550a5b8fde49f7aa