Ask what keeps a website secure and you will often get a single answer: keep it updated. That is true, and it is the most important habit, but it is one layer of several. A site that stays safe over years does so because a number of independent protections each do their part, so that when one is imperfect, as every protection sometimes is, another is already standing behind it. Security people call this defense in depth. This article walks through the layers as they apply to a business website, in plain terms, so you know what a well-protected site actually consists of.
Layer one: the edge
Before a request reaches your website it passes through an edge: the point where traffic from the internet enters your infrastructure. At the edge we terminate TLS, so every connection is encrypted with certificates that renew automatically. We run a web application firewall that inspects each request against a maintained rule set and discards the ones that match known attack patterns. And we apply rate limits, so a script hammering a login page or a search box is slowed down long before it affects anyone else.
The edge is where volume is handled. Most of what hits any public website is automated, and most of that is filtered here without the application ever seeing it. The result is that your Drupal site spends its capacity on visitors.
Layer two: the runtime
Your site runs inside containers we build ourselves from minimal images. The application code is mounted read-only. The container has no shell and no package manager. It runs as an unprivileged user with the few capabilities it needs and nothing more. Outbound connections are restricted to the destinations the site legitimately uses.
None of this is visible from outside, and all of it changes what an attacker could do with a foothold. Code that cannot be modified in place cannot be quietly altered. A process that cannot open a shell cannot be turned into a tool. The runtime layer is about limiting consequences, on the assumption that no single layer above or below it is perfect.
Layer three: current software
This is the layer everyone knows. Drupal's security team publishes advisories on a fixed weekly schedule, and we apply security releases for core and contributed modules as they appear. The same discipline covers PHP, the database, the web server and the operating system inside our images, which we rebuild and rescan for known vulnerabilities on a regular cadence rather than waiting for a reason.
Currency is a habit rather than an event. A site that receives its updates every week is always a small step from the latest release, which keeps each update small, low-risk and boring. That is the goal.
Layer four: the application itself
Drupal was designed with security as a first-class concern. Its database layer, form system and rendering pipeline handle the most common web vulnerabilities by default, so that a developer writing ordinary code gets protection without asking for it. We build on that by reviewing every contributed module before it reaches a site, by writing custom code within Drupal's own APIs rather than around them, and by scanning our code with static analysis as part of every release.
Configuration matters as much as code here: which text formats are allowed, what files can be uploaded and where, how errors are displayed. These are small settings with outsized effect, and they are part of every launch checklist.
Layer five: people and access
Most incidents anywhere on the web begin with an account, not a vulnerability. So this layer is about who can log in and what they can do once they have. Every account belongs to a named person. Roles grant the least access that lets someone do their job. Two-factor authentication protects every account that can change content or configuration. Former staff lose access the day they leave. Login attempts are limited and logged.
This is the layer where we rely most on our clients, and it is why we spend time on the habits we recommend to every team. Technology sets the defaults; people keep them.
Layer six: knowing what is happening
A protected site is also a watched one. We monitor availability, response times, error rates, certificate expiry, failed logins and changes to files that should never change. Alerts reach a person. Logs are kept long enough to reconstruct what happened, and they are stored where the site itself cannot alter them.
Monitoring is what turns an unusual event into a short story instead of a mystery. It also keeps every other layer honest, because a filter that stops working or a job that stops running is noticed the same day.
Layer seven: the ability to recover
Finally, the layer for the day something still goes wrong. Backups run on a schedule, are stored separately from the site, are kept according to a retention policy, and are restored in regular drills so that we know how long recovery takes. Every release is kept, so rolling back to a known-good version is a single step. The point is not that we expect to need this often. The point is that knowing recovery is fast changes how every other decision feels.
Why the layers matter more than any one of them
Each layer here is ordinary. Together they mean that a problem in one place is contained by the others: a module vulnerability that is exploited before the patch is applied still faces a firewall, a read-only runtime, restricted permissions and monitoring. Depth is what turns a bad day into a short one.
Every site on our managed platform gets all seven layers as a matter of course, and every site we maintain is reviewed against them. If you would like to see how yours measures up, we are happy to walk through it, layer by layer.