Some of the most effective protections a website can have cost nothing and take an afternoon. They are settings rather than software: a handful of response headers, a correctly configured certificate, a few rules about what the server will and will not say about itself. Browsers enforce most of them on the visitor's behalf, which means the protection travels with every page view without any code running on your side. This article is about those basics, what each one does in plain terms, and why we treat them as part of every launch rather than as an optional extra.
TLS everywhere, renewed automatically
Encryption in transit is the foundation. Every page, every asset and every form submission travels over HTTPS, so nobody between the visitor and your server can read or alter it. The interesting part is not turning it on, which every host does today, but keeping it on without anyone thinking about it. Certificates expire. A site whose certificate lapses shows every visitor a full-screen warning, and it happens on a weekend more often than chance would suggest.
We issue certificates automatically at the edge, renew them weeks before they expire, and monitor expiry as one of the signals that reach a person. The plain HTTP version of the site does one thing: redirect to HTTPS. And we tell browsers to remember that preference with a header called Strict-Transport-Security, so that even a mistyped link goes straight to the encrypted version.
Security headers: instructions to the browser
When your server sends a page, it can include headers that tell the browser how to treat it. Several of them close off entire categories of attack at no cost to the visitor's experience.
- Content-Security-Policy lists where scripts, styles, images and frames are allowed to load from. A script injected from an unexpected origin simply does not run. This is the most powerful header and the one that takes the most care to write, because it has to describe every legitimate source your site uses.
- X-Frame-Options or its modern equivalent in the policy above prevents other sites from embedding yours in a hidden frame and tricking visitors into clicking things.
- X-Content-Type-Options stops browsers from guessing what kind of file they received, which removes a class of tricks involving files that pretend to be something else.
- Referrer-Policy controls how much of your URL is shared when a visitor clicks a link to another site. Sensible defaults keep internal paths and query strings private.
- Permissions-Policy declares which browser features your pages may use, such as the camera, microphone or location. Declining features you do not need means an injected script cannot use them either.
Free tools grade a site on these headers in seconds. We check them at launch and after every change to the edge configuration, and our rendered server configuration ships them by default.
Cookies that behave
Session cookies are how a logged-in editor stays logged in, and their flags decide how they can be misused. The Secure flag keeps them off unencrypted connections. HttpOnly keeps them away from scripts. SameSite restricts when other sites can cause a browser to send them. Drupal sets sensible defaults, and we verify that nothing in the hosting layer or a contributed module has loosened them.
Saying less about yourself
A server that announces its exact software versions in every response is giving away information for free. So is a site that serves its changelog, its readme, its installation script or its version file to anyone who asks. None of these are vulnerabilities on their own. They are conveniences for someone deciding where to look next. Our server configuration removes version banners and returns a plain not-found for documentation and installer files, on every site we host, without anyone having to remember.
Error pages that stay quiet
A development setting that prints full error details to the screen is invaluable on a developer's machine and a problem on a live site, where a single mistyped URL can reveal file paths, database structure and library versions. Production sites log errors privately and show visitors a friendly page. This is one line of configuration, and it is one of the first things we check on any site that comes to us.
Login pages with limits
Drupal limits repeated login attempts by default, both per account and per address, and logs each failure. We keep those limits in place, watch the logs, and add two-factor authentication for every account that can change content or configuration. The login page is the front door, and the goal is for it to be boring for anyone who does not have a key.
Why the basics belong in the platform
Each item above is simple, and that is exactly why they are so often missed: they belong to nobody in particular, so they are done once and then forgotten, or never done at all. Our answer is to make them properties of the platform rather than tasks for a person. The managed hosting layer renders server configuration from a template that already includes the headers, the redirects, the file rules and the version silence. A new site gets them on day one. A change to the template reaches every site on the next deploy. Nobody has to remember, which is the only reliable way to make sure it happens.
If you would like to know how your site scores on these basics, the free header checkers are a good first look, and we are happy to read the result with you and fix whatever it turns up. It is usually an afternoon well spent.