HTTP Security Headers
Utilising the Browser as a Line of Defence
“Technology trust is a good thing, but control is a better one.”
― Stephane Nappo
HTTP security response headers restrict modern browsers from encountering website vulnerabilities. These headers bolster an additional layer of security, preventing many exploits such as XSS, clickjacking attempts, CSRF (Cross Site Request Forgery) and other threat vectors. Some of these features are easy to implement where others such as CSP (Content Security Policy) take more work.
Data Breach Report
Verizon released a Data Breach Investigation Report in 2019, revealing that a high percentage of breaches were at the application layer.
Content Security Policy
In 2019, usage statistics show only 55,000 of the top 1 million websites have an enforced Content Security Policy in place.
Some HTTP headers provide more protection than others, however, strength in numbers applies here and each compliments the other. Imagine a building with many entrances, but only the front entrance has a padlock. Any would-be burglar would easily identify a breach point to gain access. Now imagine the same building but each entrance is padlocked, deadbolted, single and double cylindered, cam locked etc. The same applies to application security, each entrance point signifies a potential exploit in an application, and each security header and it’s directives a hardened unique bolt of protection against a possible breach.
- X-Frame-Options – Anti Clickjacking
- X-Content-Type-Options – Prevents MIME sniffing
- Strict-Transport-Security – Enforces https access
- Feature Policy – Enables feature blocking resources
- Referrer-Policy – hides or displays referring sites based on directive
- X-XSS-Protection – protects against cross site scripting attacks
- Expect-CT – ensures enforcement of valid certificates
- Content-Security-Policy – whitelist resources to be loaded by the browser