Public Web Server Pattern

Key Control Areas

• Access Control and Session Management (AC-01, AC-03, AC-07, AC-09, AC-10, AC-11, AC-12): The access control family is central to public web server security because every user interaction involves an authentication and authorisation decision. AC-03 (Access Enforcement) ensures the application enforces role-based or attribute-based access on every request, not just at login. AC-07 (Unsuccessful Login Attempts) implements account lockout or progressive delays to resist credential brute-forcing -- critical for internet-facing login pages. AC-10 (Concurrent Session Control) and AC-12 (Session Termination) prevent session hijacking attacks by limiting active sessions and enforcing idle timeouts. AC-11 (Session Lock) protects unattended authenticated sessions. AC-09 (Previous Logon Notification) gives users visibility into potentially compromised accounts. Implementation should include secure session token generation (cryptographically random, sufficient entropy), HTTPOnly and Secure cookie flags, SameSite attributes to mitigate CSRF, and server-side session storage rather than trusting client-side state.
• Configuration Management and Hardening (CM-02, CM-03, CM-05, CM-07): Web servers ship with default configurations designed for developer convenience, not production security. CM-02 (Baseline Configuration) requires establishing a hardened baseline: disable unnecessary modules, remove default pages, restrict HTTP methods to those required, configure secure headers (X-Content-Type-Options, X-Frame-Options, Content-Security-Policy, Strict-Transport-Security), and disable directory listing. CM-07 (Least Functionality) enforces removal of all services, ports, and features not required for the application to function. CM-03 (Configuration Change Control) ensures that every change to the server or application configuration passes through a controlled review and approval process. CM-05 (Access Restrictions For Change) limits who can deploy code or modify configurations, preventing insider threats and reducing the blast radius of compromised credentials.
• Audit and Monitoring (AU-03, AU-07): Internet-facing systems generate high volumes of traffic, making effective log management essential for detecting attacks. AU-03 (Content Of Audit Records) specifies that web server and application logs must capture sufficient detail for forensic analysis: source IP, timestamp, HTTP method and URI, response code, user agent, authenticated user identity, and request payload hashes for sensitive transactions. AU-07 (Audit Reduction And Report Generation) addresses the practical challenge of finding attack signals in massive log volumes. Implement centralized log aggregation (SIEM), automated alerting on anomalous patterns (unusual error rates, geographic anomalies, SQL injection signatures in URLs), and regular manual review of security-relevant events. WAF logs, CDN logs, and application-level audit trails should all feed into the same analysis pipeline.
• Continuity and Disaster Recovery (CP-02, CP-03, CP-06, CP-07, CP-09, CP-10): Public web servers are often business-critical, and their unavailability directly impacts revenue, reputation, and customer trust. CP-02 (Contingency Plan) must include web-specific scenarios: DDoS sustained beyond CDN capacity, web application compromise requiring emergency takedown, certificate expiry, and DNS hijacking. CP-09 (Information System Backup) must cover not just data but application configuration, TLS certificates, WAF rulesets, and DNS records. CP-06 and CP-07 (Alternate Storage and Processing Sites) enable geographic redundancy to survive regional outages. CP-10 (Recovery And Reconstitution) defines how to rebuild a compromised web server from known-good baselines rather than attempting to clean a potentially backdoored system. Regular DR testing (CP-03) validates these procedures work under pressure.
• Secure Development and Engineering (SA-03, SA-08, SA-10): The security of a public web server ultimately depends on the quality of the code it runs. SA-08 (Security Engineering Principles) mandates that secure design principles -- least privilege, defence in depth, fail-secure defaults, separation of duties -- are applied throughout the application architecture. SA-03 (Life Cycle Support) ensures that security is embedded in every phase of the SDLC: threat modelling in design, secure coding standards in development, SAST/DAST in testing, and security review before deployment. SA-10 (Developer Configuration Management) controls the integrity of the development and build pipeline -- compromised build systems can inject backdoors that bypass all other controls. Implement signed commits, reproducible builds, and separation between development, staging, and production environments.
• Vulnerability and Risk Management (RA-03, RA-05, CA-02, CA-04): Public web servers require continuous security assessment because the threat landscape evolves faster than patch cycles. RA-05 (Vulnerability Scanning) must include automated web application scanning (DAST tools like OWASP ZAP or Burp Suite), infrastructure vulnerability scanning, and dependency checking for known-vulnerable libraries (SCA). RA-03 (Risk Assessment) should be performed before deploying new features or making significant architectural changes. CA-02 (Security Assessments) mandates periodic penetration testing by qualified assessors -- annual at minimum, with additional testing after major releases. Bug bounty programs extend assessment coverage to the global security research community.
• Communications Security and Cryptography (SC-05, SC-08, SC-09, SC-11, SC-20): All communications between clients and the public web server must be encrypted in transit. SC-08 (Transmission Integrity) and SC-09 (Transmission Confidentiality) require TLS 1.2 or 1.3 with strong cipher suites, automated certificate management, and HSTS headers with preloading. SC-05 (Denial Of Service Protection) addresses the ever-present DDoS threat through rate limiting, CDN-based scrubbing, anycast DNS, and application-level throttling. SC-20 (Secure Name/Address Resolution) protects against DNS-based attacks through DNSSEC, CAA records, and monitoring for unauthorized certificate issuance via Certificate Transparency logs. SC-11 (Trusted Path) ensures that authenticated sessions cannot be intercepted or replayed through man-in-the-middle attacks.

When to Use

Any organisation deploying web applications or APIs that are accessible from the public internet. This includes customer-facing portals, e-commerce platforms, SaaS applications, public APIs, content management systems, marketing websites handling form submissions, and any web-based service that processes user input. The pattern is essential when the application handles authentication credentials, personal data, financial transactions, or any information subject to regulatory protection. Even static websites benefit from the infrastructure hardening aspects of this pattern if they share hosting with dynamic applications.

When NOT to Use

Purely internal web applications that are not exposed to the internet and are protected by VPN or zero-trust network access may not require the full scope of this pattern, though many controls remain relevant. Applications that serve only static content with no user input, no authentication, and no backend integration have a significantly reduced attack surface and may apply a subset of these controls. This pattern should not be used as a substitute for the Cloud Computing pattern (SP-011) when the web application is deployed on cloud infrastructure -- both patterns should be applied in combination.

Typical Challenges

The most persistent challenge is keeping pace with the evolving threat landscape. New vulnerability classes emerge regularly, and the time between public disclosure and active exploitation continues to shrink -- often measured in hours rather than days. Legacy web applications carry accumulated technical debt: outdated frameworks, deprecated TLS configurations, inline scripts that prevent effective Content Security Policy deployment, and authentication mechanisms that predate modern standards. Balancing security controls with user experience is a constant tension: aggressive rate limiting blocks legitimate users, overly strict CSP breaks functionality, and MFA adds friction to conversion funnels. Third-party components (JavaScript libraries, CDN-hosted resources, analytics tags) extend the attack surface beyond the organisation's direct control and introduce supply chain risks. Misconfiguration remains a leading cause of web server compromise -- default settings, exposed admin interfaces, verbose error messages leaking stack traces, and forgotten test endpoints are discovered by automated scanners within minutes of deployment. DDoS attacks can be volumetric (overwhelming bandwidth), protocol-based (exhausting connection state), or application-layer (targeting expensive operations), each requiring different mitigation strategies.

Threat Resistance

This pattern addresses the full spectrum of web application threats. Injection attacks (SQL injection, command injection, LDAP injection, XSS) are mitigated through input validation, parameterised queries, output encoding, and WAF rules. Authentication and session attacks (credential brute-forcing, session hijacking, session fixation, CSRF) are addressed by access control and session management controls. Server-side request forgery (SSRF) and insecure direct object references are constrained by network segmentation and access enforcement. Denial of service attacks are absorbed by CDN and rate limiting infrastructure. Cryptographic failures (expired certificates, weak ciphers, missing HSTS) are prevented by communications security controls. Supply chain attacks against third-party dependencies are mitigated through software composition analysis and integrity verification. Configuration drift and exposed admin interfaces are caught by continuous vulnerability scanning and baseline monitoring. Data exfiltration following compromise is limited by network segmentation, audit logging, and incident response capabilities.

Assumptions

The web application uses standard HTTP/HTTPS protocols and is accessed primarily through web browsers or programmatic API clients. A DMZ or equivalent network segmentation architecture is in place, separating internet-facing systems from internal networks. The organisation has a secure development lifecycle with code review and testing capabilities. TLS certificate management infrastructure exists. The application does not handle state exclusively on the client side -- server-side session management is available.

Developing Areas

• HTTP/3 (QUIC) is being adopted rapidly by major browsers and CDNs, but security monitoring tooling has not kept pace. QUIC's UDP-based transport and built-in encryption make traditional network-based inspection (IDS/IPS, packet capture) largely ineffective, as the protocol encrypts not just payload but most header metadata. Organisations that rely on network-level inspection for threat detection must re-architect their monitoring to use endpoint or application-layer telemetry, a transition that most have not yet begun.
• Advanced bot management has become a critical capability for public web servers, but the distinction between legitimate automated traffic and malicious bots is increasingly difficult to make. Sophisticated bots use residential proxy networks, browser fingerprint spoofing, and AI-generated behavioural patterns that defeat traditional CAPTCHAs and rate limiting. The bot management market (Akamai, Cloudflare, DataDome) is evolving rapidly, but false positive rates that block legitimate users remain a significant challenge for high-traffic consumer-facing sites.
• Client-side web supply chain attacks (Magecart-style) represent a growing threat that server-side security controls cannot fully address. Attackers compromise third-party JavaScript libraries, tag managers, or CDN-hosted resources to inject card skimmers, credential harvesters, or cryptominers directly into the user's browser. Subresource Integrity (SRI) and Content Security Policy (CSP) provide partial protection, but the dynamic nature of modern web applications -- with dozens of third-party scripts loaded on each page -- makes comprehensive client-side supply chain security an unsolved problem.
• Edge computing is pushing application logic closer to users through CDN-hosted functions (Cloudflare Workers, AWS Lambda@Edge, Vercel Edge Functions), fundamentally changing the web server security model. Security controls that assumed a centralised origin server must now account for code executing across hundreds of edge nodes with different runtime environments, limited observability, and novel attack surfaces including edge-specific injection vectors and function isolation failures. Security tooling for edge compute is nascent and primarily vendor-specific.