HTTP security headers: a practical guide for web freelancers and agencies

HSTS, CSP, X-Frame-Options and the rest: understand HTTP security headers, detect missing ones on client sites, and turn them into a structured commercial lever.

A client calls you in a panic. Their cyber insurer just sent them a scan report flagging seven missing HTTP headers on their WordPress showcase site. They do not understand a thing in the document, ask if it is serious, and especially if you can fix it before Monday's meeting. This scenario, web freelancers and agencies live it almost every month.

HTTP security headers have become a central topic in technical audits, CISO questionnaires, and compliance requests. Yet they remain poorly understood by end clients and often underused by web professionals who could make them a serious commercial lever.

This guide gives you the precise vocabulary, the concrete business risks, and the method to turn detection of these headers into a credible sales argument, without falling into indigestible OWASP jargon.

What HTTP security headers really are

HTTP headers are metadata exchanged between the browser and the server on every request. Most handle invisible technical aspects like compression, content type, or caching. A specific category is used solely to strengthen the security of the browser viewing the page.

A line of defense on the browser side

A security header does not modify the application code. It instructs the user's browser on how to behave during navigation. Block iframe embedding, refuse unauthorized scripts, force encrypted connection, limit information transmitted to a third-party site — all these rules go through headers added in the server's HTTP response.

This approach has a considerable advantage for agencies and freelancers. Configuration happens at the server or CMS level, without rewriting a single line of the existing site. A clean deployment can take a few minutes on a standard Apache or Nginx setup, and the protection benefits are immediate.

Why clients are talking to you about it more and more

Three factors fuel the pressure. Cyber insurers systematically include security scans in their underwriting questionnaires. Large-account CIOs require a minimum header level before validating a web vendor. And free scanning tools like Mozilla Observatory or securityheaders.com make these audits accessible to any mildly curious communications manager.

The result is that clients arrive with reports they do not understand and requests that land directly on their WordPress freelancer's or agency's desk.

The six headers you must know by heart

Among the twenty or so existing headers, six cover 90% of auditor and automated scanner expectations. Mastering them is enough to cover the vast majority of client engagements.

Strict-Transport-Security, the most critical

The HSTS (Strict-Transport-Security) header forces the browser to use HTTPS exclusively for your site, even if the user types the URL in HTTP or follows an unsecured link. According to MDN Web Docs, this header neutralizes an entire class of Man-in-the-Middle attacks that exploit the very first unencrypted request of a session.

Typical configuration combines three directives: max-age which defines the browser memorization duration, includeSubDomains to extend protection to subdomains, and preload to request inclusion in the browser preload list. Before activating includeSubDomains, it is imperative to verify that all subdomains are accessible in HTTPS, otherwise HTTP services will become inaccessible.

This header complements work on the SSL certificate and HTTPS redirect detailed in a dedicated guide. Both mechanisms work in tandem.

Content-Security-Policy, the most powerful

CSP is the most granular and most effective header against Cross-Site Scripting attacks. It allows you to explicitly declare the sources authorized to load JavaScript, CSS, images, fonts, or iframes on your page. Anything coming from an undeclared origin is blocked by the browser.

The difficulty of CSP lies in its configuration. A poorly calibrated CSP breaks site display, blocks Google Analytics, prevents loading a chat widget, or makes Google fonts disappear. Best practice is to start in Content-Security-Policy-Report-Only mode, which signals violations without blocking anything, then progressively tighten the rules. Evaluators like Google's CSP Evaluator help spot overly permissive policies.

X-Frame-Options and clickjacking protection

This header prevents a page of your site from being loaded in an iframe by a third-party site. The classic attacker maneuver consists of displaying your page in an invisible frame, overlaying it with fake buttons, and hijacking user clicks toward actions they did not intend to trigger. This clickjacking technique typically targets authenticated areas, payment forms, or validation pages.

Three possible values: DENY completely forbids iframe display, SAMEORIGIN allows it only from your own domain, and the modern frame-ancestors directive in CSP is progressively replacing this header.

X-Content-Type-Options and MIME sniffing

Without this header, some browsers try to guess the real type of a file by analyzing its content, regardless of the Content-Type declared by the server. An attacker can exploit this tolerance to execute a malicious script that was uploaded as an image. The nosniff value disables this behavior and forces the browser to respect the declared type.

Its activation is trivial, with no known side effects, and it should be present on all production sites. It is one of the easiest tests to pass in a security audit, and paradoxically one that comes up most often as missing in automated scans.

Referrer-Policy, Permissions-Policy, and confidentiality headers

Two additional headers deserve particular attention in the GDPR context and growing privacy expectations.

Controlling information transmitted to third-party sites

Referrer-Policy controls what your site transmits in the Referer header when a user clicks an outgoing link. By default, most browsers send the full URL of the previous page, sometimes including sensitive parameters like a session ID or password reset token.

A policy like strict-origin-when-cross-origin transmits only the site origin (domain) to external sites, not the full path. It is the right compromise between privacy and analytics tool compatibility. For sites handling sensitive data, no-referrer cuts this transmission completely.

Controlling sensitive browser APIs

Permissions-Policy is the evolution of the old Feature-Policy header. It allows declaring which browser APIs can be used by the page and by the iframes it embeds. Geolocation, camera, microphone, sensors, video autoplay, fullscreen — all these uses can be authorized, limited to same origin, or completely disabled.

This configuration protects users against third-party iframe abuse that would try to access their camera or position without their knowledge. On a classic showcase site, a default restrictive Permissions-Policy is excellent security hygiene and breaks nothing.

The concrete business risks of missing headers

For a freelancer or agency, the technical argument is not enough. You must translate each missing header into a business consequence understandable by the client.

Reputation and external scanner alerts

Free scanners like securityheaders.com assign an A+ to F grade to the site, visible to anyone. A corporate showcase site displaying an F because it lacks HSTS, CSP, and X-Frame-Options becomes an easy target for competing salespeople, prospecting cybersecurity consultants, and tech journalists. Negative visibility has a real reputational cost.

CISO questionnaires and B2B procurement

In a B2B context, selling a service or onboarding a large-account client goes through a compliance questionnaire. HTTP security headers systematically appear in these questionnaires. A site that does not implement them can see a contract blocked or returned for corrections, with several weeks of delay at stake. This is exactly the type of blocker a freelancer can anticipate by integrating verification into their onboarding process.

Real attacks that exploit missing headers

Beyond audits, real attacks exist. OWASP ranks clickjacking, XSS injections, and MITM attacks among the most common vectors on web applications. An e-commerce site without HSTS exposes its customers to cart interception during a connection from public wifi. A members area without X-Frame-Options can have its actions hijacked by a malicious site. These vulnerabilities cost in remediation and customer trust.

How to detect missing headers without losing a day

Manual detection is possible but time-consuming. A freelancer managing ten to twenty client sites cannot afford to inspect each header by hand.

Manual methods for troubleshooting

Three quick tools for one-off verification. The curl -I https://mysite.com command displays response headers in the terminal. The browser inspector, Network tab, lets you read the headers of any request. Online sites like securityheaders.com or Mozilla Observatory produce a report with grades and recommendations.

These methods are useful for a one-off check or to understand a report received from a client. They quickly become inefficient as soon as you go beyond a few sites to track.

Automation for a client portfolio

The benefit of an automated audit like Orilyt's is to verify in seconds the presence and configuration of the main security headers across multiple pages and multiple client sites. A raw diagnosis without interpretation leaves the client in the dark, which justifies the systematic translation of technical jargon into business observations in every report.

In audits run with Orilyt, it is regularly observed that more than 60% of WordPress showcase sites audited for the first time have no security header configured, not even HSTS on a site nonetheless served in HTTPS.

Automated diagnosis allows detecting HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy in one pass, with a client-readable report. That is what differentiates a tool designed for agencies from a raw technical scanner. The report can then be used as a basis for commercial conversation, which we detail in our guide on how to turn an audit into a maintenance contract.

Turning detection into a commercial argument

Identifying missing headers on a client site is one thing. Making it a sales trigger is another.

The pitch that works in a client meeting

The posture that converts is not technical. It starts with risk and ends with the solution. An effective speech holds in three sentences.

Your site has none of the six standard security headers recommended by OWASP and Mozilla. A prospect or insurer running your URL through a scanner will immediately see an F grade, which can block a signature or trigger a compliance request. The fix takes one hour on the server side and I can integrate it into the maintenance contract.

This approach respects the FIA method (Fact, Impact, Action) which structures audit reporting. The client does not receive a technical report, they receive an actionable proposal.

Integration into a recurring maintenance offer

Security headers are not configured once and forever. A CDN change, a server migration, a major CMS update can break the configuration. Continuous monitoring of their presence and correct configuration is part of the recurring services a freelancer can bill without additional commercial effort.

Concretely, adding a "Monthly HTTP security headers monitoring" line to a 150-euro per month maintenance contract is legitimate and justifies the rate in the client's eyes. A structured audit report for your clients turns each monthly pass into a concrete deliverable that maintains the value perception.

Avoiding excessive promises

Security headers reduce risk, they do not eliminate it. Never promise a client that a CSP configuration makes their site unattackable, that an A+ score on securityheaders.com guarantees full GDPR compliance, or that no other measures are needed.

These shortcuts come back to bite the provider at the first incident. The right wording stays: your site now applies the security standards recommended by Mozilla and OWASP, which covers the most common attack vectors on the browser side.

Why Orilyt simplifies this approach for freelancers

Orilyt analyzes in read-only mode all HTTP headers of a site and flags those that are missing or misconfigured, in the Security category of the audit.

A client-readable report

The client report generated by Orilyt translates technical vocabulary into business observations. "HSTS missing" becomes "The secure connection is not enforced on your site, which exposes your visitors to interception during connections from public networks." This translation, which would take twenty minutes per header for a freelancer, is automated in every audit. That is precisely the differentiator that distinguishes Orilyt from a classic technical scanner.

Time savings for a portfolio of sites

Orilyt allows auditing several client sites in succession, storing each audit's history, and comparing results from one month to the next. For a freelancer managing fifteen sites under maintenance, monthly verification of security headers goes from several hours to a dashboard review of a few minutes. This efficiency frees up time for prospecting and higher-value engagements. You can review the plans matching your activity on the Orilyt pricing page.

Orilyt's positioning is simple: simplify diagnosis and reporting, not replace the freelancer's expertise. Effective header configuration remains a technical intervention that belongs to the professional, and that is precisely what allows justifying a recurring maintenance contract.

In summary, HTTP security headers have become a standard expected by clients, insurers, and CIOs. The six essential headers cover the vast majority of demands: HSTS forces HTTPS, CSP blocks unauthorized scripts, X-Frame-Options protects against clickjacking, X-Content-Type-Options neutralizes MIME sniffing, Referrer-Policy controls information leaks, Permissions-Policy limits access to sensitive APIs.

For a freelancer or agency, the real opportunity is not to become an OWASP expert, it is to quickly detect missing headers on client sites and turn them into a structured commercial lever. A monthly audit, a clear report, a proposed action — and the approach turns into a billable recurring service.

Orilyt detects security headers in seconds, produces a report directly usable in client meetings, and integrates into a continuous maintenance workflow. It is the tool you need to turn this technical requirement into a credible sales argument.

Your most frequent questions

Sources and references

• MDN Web Docs, Strict-Transport-Security — official documentation of the HSTS header, its directives and best practices.
• MDN Web Docs, Content-Security-Policy — complete reference on CSP and its directives.
• OWASP, HTTP Security Response Headers Cheat Sheet — official OWASP recommendations on headers to implement.
• Google Web Fundamentals, Content Security Policy — Google's practical guide on progressive CSP deployment.
• Mozilla Observatory — free tool for evaluating a site's security headers.