Cybersecurity and resilience architecture for websites: treating the web as a technical system

A modern website is no longer a set of documents on a server. It renders on demand, authenticates users, talks to databases, runs scheduled jobs, exposes APIs and is read every minute by search engines, AI crawlers and vulnerability scanners. That makes it a distributed software system with an attack surface — and it deserves the same discipline we apply to industrial control systems: a cybersecurity and resilience architecture that is designed in, layered and testable, not bolted on after the first incident.

This site is still growing. New sections, features and content arrive step by step, and I'm grateful to everyone who visits, explores and comes back — every visit shows me what matters most to readers. As the platform has grown, one topic has moved to the center of how I think about it: Cybersecurity & Resilience Architecture (CRA), and why it applies to websites as much as to machines.

A note on the acronym: in this article CRA means an architectural discipline. It is not the EU Cyber Resilience Act, Regulation (EU) 2024/2847, which shares the abbreviation and sets legal requirements for products with digital elements. The two overlap in spirit — security by design, vulnerability handling, updates over the lifecycle — but applying the principles below says nothing about whether a product meets that regulation.

The website as a system: mapping the attack surface

A contemporary web platform typically combines:

• server-side rendering, where every request executes code on a server or in a function
• authenticated areas with sessions, tokens and roles
• integrated databases and object storage holding content, user data and files
• automated workflows: scheduled jobs, background tasks, webhooks
• APIs consumed by the front end and by other systems
• content management tools with write access to production data
• continuous machine traffic: crawlers, AI agents, uptime monitors and hostile scanners

Each of these is an entry point, and each crosses a trust boundary — between the browser and the server, between the server and its data stores, between the platform and third-party services. Threat modeling starts by drawing those boundaries explicitly. The same thinking sits behind the zones and conduits of IEC 62443: group assets with common security requirements, then control every path between groups.

Principle 1: separation of concerns at the trust boundary

The browser is untrusted territory. Everything shipped to it — JavaScript bundles, source maps, serialized page state, HTML comments — can be downloaded and read by anyone. In practice this means:

• Secrets never reach the client. API keys, database credentials and signing keys live in server-side environment variables, scoped to the runtime that needs them (build, functions, or both) and to the deploy context (production vs. preview). Build pipelines should scan their output for known secret values and fail the build when one would be published.
• Confidential logic and text stay server-side. Code splitting does not protect anything: a route that is "hidden" from navigation is still in the bundle. Prompts, internal drafts and business rules belong in server-only modules that are executed, never shipped.
• Serialized state is minimal. Server rendering hands data to the client for hydration. Return exactly the fields the page renders, not whole database rows.

Principle 2: authorization is enforced on the server

Hiding a button is a user-experience decision, not a security control. Every mutating request and every request for protected data must be checked server-side against the caller's identity and role.

A robust pattern uses signed tokens — typically JSON Web Tokens — issued by an identity service, carried in a Secure, HttpOnly, SameSite cookie or an Authorization header, and verified on every call. The token carries role claims; the server enforces role-based access control and the principle of least privilege: being logged in is never the same as being allowed. Where signups are open, an authenticated user must still hold an explicit role before any write succeeds.

For administrative access, multifactor authentication and single sign-on for the team that operates the platform close the most common path into a system: a reused password. Machine-to-machine access uses separate, long, rotatable bearer tokens — never tokens in query strings, where they leak into logs, browser histories and referrer headers.

Principle 3: controlled visibility

Public and private content need a hard boundary, not a convention. Three layers work together:

1. Access control decides who may read a resource at all. A private resource answers unauthorized requests with a plain 404 rather than a 403, so it doesn't confirm that it exists.
2. Indexing directives — noindex meta tags or X-Robots-Tag headers, robots.txt rules and curated sitemaps — tell well-behaved crawlers what is meant to be public. They are a courtesy protocol, not a lock: robots.txt is publicly readable and is ignored by hostile bots, so it must never be the only thing keeping a path private.
3. Cache policy prevents private responses from being stored where others can retrieve them. Personalized or protected responses carry Cache-Control: private, no-store; only anonymous, public pages are cached at the edge.

Files deserve special care. Public assets can sit behind a CDN; private files belong in a separate, access-controlled store and are streamed through a function that checks authorization first. User-uploaded formats that can carry active content — SVG, HTML — should be served as downloads (Content-Disposition: attachment) rather than rendered inline on the site's own origin.

Principle 4: defense in depth across the delivery chain

Defense in depth means that no single control is load-bearing. For a web platform the layers run from the network edge to the data store:

• Transport security. TLS everywhere, with automatically issued and renewed certificates, HTTPS redirects and HTTP Strict Transport Security (HSTS) so browsers never fall back to plain HTTP.
• Edge protection. A globally distributed CDN absorbs volumetric traffic and mitigates network-layer DDoS attacks before they reach application code. A web application firewall and traffic rules add filtering by path, method, header or geography, and rate limits cap how often a client may hit expensive endpoints such as login, search or form submission.
• Security headers. A Content Security Policy limits where scripts, styles and frames may load from; X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy and frame-ancestors restrictions remove whole classes of attacks — clickjacking, MIME sniffing, referrer leaks — at almost no cost.
• Isolated compute. Serverless functions run in short-lived, isolated execution environments. There is no long-running server to patch or to persist on, and each function receives only the configuration it needs.
• Input validation. Every server endpoint validates its input against a schema, uses parameterized queries for the database and treats data from forms, webhooks and feeds as untrusted. Forms get spam defenses — honeypot fields, minimum fill times — and server-side outbound requests are restricted to public hosts, so they can't be turned against internal addresses (server-side request forgery).
• Data protection. Encryption in transit and at rest, data residency pinned to a region where personal data is involved, and retention rules that delete what is no longer needed. Data that isn't stored can't leak.

Principle 5: resilience against automated access

Most traffic on a public website is automated. Some of it is welcome — search engines, AI systems, monitoring — and some of it probes for exposed admin panels, configuration files and known vulnerabilities. A resilient architecture assumes this traffic is constant:

• Static and cached responses serve the bulk of requests from the edge, so a crawler burst or a scan doesn't translate into function invocations or database load. Cache tags allow targeted purges when content changes, and stale-while-revalidate keeps pages available while fresh copies are built.
• Predictable error behavior. Unknown paths return uniform 404s without stack traces, framework versions or directory listings.
• Bot management and rate limiting separate legitimate crawlers from abusive ones and keep expensive operations out of reach of brute force.
• Machine-readable entry points — sitemaps, structured data, llms.txt — give AI systems and search engines a curated, intentional view of public content, which reduces the incentive to crawl everything.

Principle 6: integrity of the release process

Resilience is decided as much at deploy time as at runtime. The release pipeline itself is part of the attack surface — see supply chain security.

• Immutable, atomic deploys. Every release is a complete, versioned snapshot that goes live in a single switch. There is no half-updated state, and a rollback to any previous deploy takes seconds because the old version still exists unchanged.
• Isolated previews. Changes are reviewed on preview deploys with their own URLs, their own environment variables and, ideally, their own database branch, so testing never touches production data. Previews can be password-protected so unreleased work isn't public.
• Versioned schema migrations. Database changes are forward-only migrations in version control: reviewable, reproducible and never edited after they have run.
• Dependency hygiene. Locked dependency versions, automated vulnerability alerts, a software bill of materials where it is required, and disciplined patch management keep known vulnerabilities from lingering in third-party code.
• Auditability. Logs of deploys, configuration changes and team access, plus function logs and security monitoring, make it possible to reconstruct what happened — the precondition for any incident response.

Why this matters now

Websites increasingly serve as knowledge platforms, documentation hubs, editorial systems, expert portals, integration points for AI tools and gateways to internal processes. A weakness in web architecture can therefore have the same impact as a weakness in traditional IT or OT environments: leaked data, manipulated content that others rely on, or a service that fails exactly when it is needed.

Applied consistently, a cybersecurity and resilience architecture protects the four properties that make a system trustworthy:

Property	What it means for a website	Typical controls
Confidentiality	Private content and data stay private	Server-side authorization, secrets management, private stores, no-store caching
Integrity	Content and workflows can be trusted	Role-based write access, input validation, immutable deploys, audit logs
Availability	The site stays reachable under load and attack	CDN and edge caching, DDoS mitigation, rate limiting
Resilience	The system recovers quickly when something fails	Atomic rollbacks, isolated previews, versioned migrations, backup and recovery

None of these controls is exotic. What turns them into an architecture is that they are chosen deliberately, layered so that each one covers for another's failure, and reviewed as the system grows.

Conclusion

This website is still growing, and I'm grateful to everyone who follows its development. As it evolves, cybersecurity and resilience architecture remains a guiding principle — not because the site is large, but because every modern web system is a technical system, and technical systems deserve structured protection.

The discipline is not reserved for industrial plants and safety-critical domains. Trust boundaries, server-side authorization, controlled visibility, defense in depth, resilience against automation and a trustworthy release process are the foundation of any website or web application that people rely on.