Security Headers

Security headers are special HTTP response headers with which a server tells the browser how to treat a page's content from a security standpoint. Instead of relying solely on application code, they push part of the protection down to the browser level, mitigating common web attacks — many of them catalogued by the OWASP project.

How security headers work

The server attaches these headers to each response, and the browser enforces the rules they contain. The most important ones include:

• Content-Security-Policy (CSP) — defines which sources scripts, styles and other assets may load from, effectively limiting XSS attacks.
• Strict-Transport-Security (HSTS) — forces connections over HTTPS and blocks attempts to reach the site over unencrypted HTTP.
• X-Frame-Options — prevents the page from being embedded in an <iframe>, protecting against clickjacking.
• X-Content-Type-Options: nosniff — stops the browser from guessing a file's MIME type.
• Referrer-Policy and Permissions-Policy — control referrer leakage and access to device features such as camera or location.

Practical application

Security headers are configured on the web server — in Apache via the .htaccess file or Header set directives, in Nginx inside the server block with the add_header directive. On shared hosting, basic headers such as HSTS are often available in the control panel with a single click once an SSL certificate is enabled.

It is worth verifying the deployment with online scanners that grade a site's header set and highlight gaps. CSP demands particular care — an overly strict policy can block the site's own scripts, so it is rolled out gradually, first in report-only mode. When configured correctly, security headers are one of the cheapest ways to meaningfully raise a website's resilience to attacks.