Public Web Server Pattern

Key Control Areas

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.

Related Patterns

Patterns that operate within or alongside this one. Click any to view.