Site security headers: what to turn on after an audit, not instead of one

In a scanner report, headers take half a page and look worse than they are. Without a hint the browser itself decides whether your site may be opened inside someone else's page, whether a script may be served as an image, and whether to remember forever that you only speak HTTPS. A few lines in the web server config straighten that out. The store does not become "tested" because of it.

What is usually worth turning on

• Permanent HTTPS and a header that asks the browser not to try the plain address again.
• A ban on framing the site in someone else's page, unless you need that for a widget.
• A ban on the browser guessing the file type. Otherwise an "image" may run as a script.
• Turn on a source policy carefully: a broken account area is worse than a missing line.

A strict source policy easily drops payment, maps and chat if it was copied from an article. It is turned on after a list of the scripts the site actually needs, and the account area and checkout are checked. That is an hour-to-a-day job, not a reason to rewrite the project.

Lexora sets these headers at the end of an audit or during maintenance, once it is clear which widgets are alive. The basic audit is free for new clients, and headers are part of it, but we do not sell them as "turnkey site protection". If a report is almost only headers and nobody looked at the account area, the next purchase is not another scanner. It is a pentest of the roles.