Security Headers: CSP, HSTS and Others
Security headers are a few lines that the server adds to each response. The visitor does not see them, but the browser understands what can and cannot be done on your site. They are configured on the server and usually do not require changing the site code.
Analogy for the Site Owner
This is an instruction for the guard at the entrance. Without it, he allows everything: any script from any domain, embedding your page into someone else's site, attempts to guess the file type. With the instruction, a list appears: these can enter, these cannot, this door should remain closed. Headers do not fix holes in the code, but they prevent them from being exploited.
What Each Header Does
| Header | What It Provides | Severity |
|---|---|---|
| Strict-Transport-Security | The browser only accesses you via HTTPS and does not revert to an open connection | Medium |
| Content-Security-Policy | Specifies where scripts can be loaded from. The main protection against XSS | Medium |
| X-Frame-Options | Prevents your pages from being embedded in a frame on someone else's site (clickjacking) | Low |
| X-Content-Type-Options | Prevents guessing the file type — otherwise, an uploaded file may execute as a script | Low |
| Referrer-Policy | Limits what address is sent to external sites when transitioning | Info |
| Permissions-Policy | Disables unnecessary browser capabilities: camera, microphone, geolocation | Info |
Alongside, cookie flags are checked — Secure, HttpOnly, and SameSite: they prevent session hijacking.
How This Relates to Business and SEO
Headers themselves do not improve rankings — they are not a ranking factor. They operate on a different front: HSTS removes the risk of an open connection, and CSP prevents external scripts from adding hidden links and redirects to pages. Such injections lead to a drop in rankings and the label "this site may harm your computer" in the browser.
How It Looks in the Security Shield Report
Header checks occur in any mode, including the quick free one. Each missing header becomes a separate finding with its severity, CWE class, and OWASP category; from them, a score from A+ to F is formed. The absence of CSP and HSTS weighs more than the absence of Referrer-Policy. For this group, auto-correction works: the service collects a ready configuration fragment — .htaccess or a block for nginx.
How to Start
- Add
X-Content-Type-Options: nosniffandReferrer-Policy: strict-origin-when-cross-origin— they almost never break anything. - Close framing:
X-Frame-Options: SAMEORIGIN— but check that you are not embedding your pages into other domains. - Ensure that all HTTP redirects to HTTPS, and only then enable HSTS.
- Leave CSP for last and start with the report mode
Content-Security-Policy-Report-Only.
In Report-Only mode, the policy does not block anything, it only reports what it would block. Let it run for a week on live traffic, analyze the reports, add the necessary domains — and only then switch to the live header. Otherwise, you risk disabling widgets, analytics, and payments.
How to Prevent Reoccurrence
Headers live in the server configuration, and it can be lost during migration, hosting changes, or CDN integration. Keep a config fragment in the repository along with the project and repeat the scan after infrastructure changes — how the service works is described in the article about Security Shield. For access to the cabinet — account security.