A website can use HTTPS and still remain insufficiently protected on the browser side. Between the server and the user’s screen, HTTP headers transmit instructions that restrict certain risky behaviours, such as loading external scripts, embedding the website in an iframe, incorrectly interpreting a file or accessing sensitive browser features. These protections are largely invisible, but they deserve a place in the technical audit of a WordPress website, a PHP application or a custom business CRM.

What are HTTP security headers used for?

A response header is information sent by the server together with the page. Some headers tell the browser what it should allow or refuse. They can reduce the impact of attacks such as script injection, clickjacking or the exploitation of content whose type has been declared incorrectly. OWASP presents them as a useful security reinforcement, not as a substitute for properly developed, updated and reviewed code.

The most useful protections to check

  • Content-Security-Policy (CSP) defines the permitted sources for scripts, styles, images, fonts and other resources. A well-designed policy can notably limit the exploitation of certain XSS vulnerabilities. It must, however, be tailored to the website.
  • Strict-Transport-Security (HSTS) instructs the browser to return automatically through HTTPS on subsequent visits. It must only be sent over HTTPS. The includeSubDomains option should only be enabled when all relevant subdomains can operate permanently over HTTPS.
  • X-Content-Type-Options: nosniff prevents the browser from guessing a content type different from the one declared by the server. This reduces certain scenarios in which a file is interpreted as executable code.
  • frame-ancestors, within the CSP, controls which websites may embed a page. X-Frame-Options remains useful for compatibility with some older browsers, while frame-ancestors provides more modern control.
  • Referrer-Policy limits the origin information transmitted when a visitor follows a link. Permissions-Policy can disable or restrict features such as the camera, microphone or geolocation when they are not required.

Why copying a ready-made configuration can break the website

An overly strict CSP can block analytics, a map, a video, online payment, a captcha or a script added by WordPress. Conversely, a policy filled with exceptions such as unsafe-inline loses part of its value. The correct approach is to inventory the resources actually used and first test the policy with Content-Security-Policy-Report-Only. This mode reports violations without immediately blocking the affected elements.

HSTS also requires caution. A long duration, includeSubDomains or registration on a preload list can make a subdomain inaccessible when its certificate or HTTPS configuration is not ready. Start with a limited duration, check the entire domain, then strengthen the rule progressively.

How to carry out a practical check

The first check can be performed in the Network tab of the browser’s developer tools or with a command that displays HTTP headers. Test the home page, the administration area, forms, the customer portal and, where applicable, the payment flow.

  • Record the headers already present and identify duplicates or contradictions.
  • List the external domains loaded by the website.
  • Prepare the rules on a staging environment or in report-only mode.
  • Test forms, analytics, maps, videos, logins and payments.
  • Deploy progressively, then monitor errors after release.

On WordPress, a plugin can add certain headers, but configuration at server, reverse proxy or CDN level is often more consistent. The main concern is preventing several layers from sending different rules. In a custom PHP application, headers should be included in a shared configuration so that every response is covered, including error pages.

A small setting that requires a real method

Security headers do not make a website invulnerable. They add a useful defensive layer around the code, updates, backups, access controls and monitoring. For a small or medium-sized business in Nice, Cannes or Monaco, the objective is not to accumulate technical rules, but to protect the journeys that matter: enquiries, bookings, payments, customer access and internal tools.

Points to check before publication

Review the OWASP and MDN recommendations at publication time, check the current compatibility of Permissions-Policy and CSP, confirm that every subdomain supports HTTPS before enabling HSTS with includeSubDomains or preload, and adapt each rule to the external services actually used by the website.