Security headers for small business websites: what to check

A brochure site, an online shop, and a booking portal have different dependencies. A useful review begins with the pages visitors use to understand your offer, submit an inquiry, or move to a payment provider. Record which domain serves each step and who maintains it. Your agency may control the website while another supplier controls a checkout or booking widget.

A missing header is a configuration observation, not proof that a website has been compromised. Conversely, five present headers do not prove that accounts, software updates, backups, or payment processing are secure. Ask for the affected response, the actual policy value, the plausible impact, and a practical next step. Our audit methodology separates public evidence from checks that require owner-authorized access.

Strict-Transport-Security tells browsers to use HTTPS for future connections after receiving the policy securely. It does not by itself protect an initial HTTP visit before the browser knows the policy. The max-age value determines how long the browser remembers it.

Before enabling includeSubDomains, inventory subdomains and confirm they support HTTPS. Otherwise an old campaign or supplier-managed subdomain can become inaccessible. Preloading needs a deliberate review, not a copied setting. Read the MDN HSTS reference with whoever manages your domain.

For a business owner, the deliverable should identify which host was checked, the observed value, and any unresolved dependency. Do not approve a domain-wide change solely because it makes a score turn green.

Content-Security-Policy controls resources and browser behaviors through directives. Its effectiveness depends on the policy, not just the header name. Broad allowances can weaken protection. Nonces and hashes can support tighter script controls, but need implementation that matches how the application serves content.

A report-only policy observes violations without enforcing that policy. It can help evaluate a proposed configuration before enforcement, but should not be reported as active blocking. Use the MDN CSP guide for the distinction and implementation details.

Ask your developer to inventory analytics, consent tools, embedded videos, booking widgets, fonts, and payment integrations. Then agree which customer journeys will be retested. A broken contact form is a real operational failure even when a security scan improves. Keep policy tuning and production deployment as explicitly approved implementation work.

Embedding and frame protection

CSP frame-ancestors specifies which parents may embed a page. Review it alongside any X-Frame-Options policy and intentional integrations. A blanket restriction can interfere with a legitimate embedded portal. The frame-ancestors reference explains its role. Record whether embedding is needed before recommending a value.

Ask for a compact evidence table rather than an unexplained grade. Each observation should include the checked URL, time, status, final destination, relevant header value, limitation, responsible owner, and retest condition. Keep personal data and confidential tokens out of screenshots and shared reports.

• Representative coverage: homepage, service or product page, inquiry route, and a normal not-found response. Separate third-party destinations from the domain you control.
• Configuration context: explain whether the host, application, or CDN appears to supply a policy; mark attribution as unconfirmed when public evidence cannot establish it.
• Priorities: distinguish a missing defense from an observed broken buyer journey. State uncertainty instead of describing every missing header as a critical vulnerability.
• Fix acceptance: describe the expected response and the customer workflow that must still work afterward, with a named implementation owner.

For example, if a service page and its inquiry route return different policies, the first task is to establish why. They may use different hosting layers. Recommend a reviewed change for the relevant layer, rather than asking someone to paste a global configuration with an unknown blast radius.

1. Define scope. List owned domains and representative routes. Public review does not require customer passwords or access to private records.
2. Capture the baseline. Save response evidence and document current buyer-facing behavior before discussing changes.
3. Agree implementation separately. Assign the developer or hosting owner, test environment, approval, and recovery plan. A public audit is not permission to change production.
4. Retest the agreed routes. Compare policy values and inspect assets, navigation, consent tools, and embedded services. Any synthetic inquiry or payment test needs its own authorization.
5. Record unresolved limits. Identify supplier-controlled pages, unsupported checks, or dependencies that still need investigation.

The public website security audit combines header observations with other public trust and security signals. The security audit cost and scope guide helps distinguish that review from monitoring and authorized deeper testing. Header findings should feed a prioritized fix plan, not a promise that the entire website is secure.

Does a missing security header mean my website was hacked?

No. A missing header is a configuration observation, not evidence of a breach. Its importance depends on the page, browser behavior, existing controls, and the customer journey involved.

Can you review headers without my website password?

Public HTTP response headers can be reviewed without a login. That review cannot confirm private server settings, account controls, or the security of code that is not publicly observable.

Will a better header score guarantee higher Google rankings?

No. We do not promise ranking improvements from a header score. Use header findings to improve browser defenses and reliability; evaluate crawling, content, and search performance separately.

Does the audit include changing my hosting configuration?

No. The audit provides evidence, priorities, and recommended next steps. Production configuration changes require a separately agreed implementation scope, owner approval, and a retest plan.