Why Web Security Matters#

Every web application exposed to the internet is under constant attack. Automated scanners probe for vulnerabilities within minutes of a new service going live. A single SQL injection or misconfigured header can expose millions of user records, destroy a company’s reputation, and trigger regulatory fines measured in percentages of global revenue.

Security is not a feature — it is a property of the system. You cannot bolt it on at the end. This section establishes the foundational mental models that underpin every subsequent topic.

The CIA Triad#

The three pillars of information security:

Extended Models#

The CIA triad is the minimum. Real-world security adds:

Attack Surfaces#

An attack surface is the sum of all points where an attacker can attempt to enter or extract data from a system.

Web Application Attack Surface Map#

┌──────────────────────────────────────────────────────┐
│                     INTERNET                         │
└────────────────────────┬─────────────────────────────┘
                         │
            ┌────────────▼────────────┐
            │      CDN / WAF          │  ← Layer 1: Edge
            └────────────┬────────────┘
                         │
            ┌────────────▼────────────┐
            │    Load Balancer        │  ← Layer 2: Network
            └────────────┬────────────┘
                         │
            ┌────────────▼────────────┐
            │    Web Server           │  ← Layer 3: HTTP headers, TLS
            │    (Nginx / ALB)        │
            └────────────┬────────────┘
                         │
            ┌────────────▼────────────┐
            │    Application Code     │  ← Layer 4: Business logic
            │    (Controllers, APIs)  │     Input validation, auth
            └────────────┬────────────┘
                         │
            ┌────────────▼────────────┐
            │    Data Layer           │  ← Layer 5: Database, cache
            │    (PostgreSQL, Redis)  │     Query construction
            └─────────────────────────┘

Common Entry Points#

Defence in Depth#

No single control stops all attacks. Defence in depth layers multiple independent controls so that a failure in one layer does not compromise the system.

┌─────────────────────────────────────────────┐
│  Layer 1: Network (WAF, firewall, DDoS)     │
│  ┌─────────────────────────────────────────┐ │
│  │  Layer 2: Transport (TLS, HSTS)         │ │
│  │  ┌─────────────────────────────────────┐ │ │
│  │  │  Layer 3: Application (auth, CSP)   │ │ │
│  │  │  ┌─────────────────────────────────┐ │ │ │
│  │  │  │  Layer 4: Data (encryption,     │ │ │ │
│  │  │  │  parameterised queries, hashing)│ │ │ │
│  │  │  └─────────────────────────────────┘ │ │ │
│  │  └─────────────────────────────────────┘ │ │
│  └─────────────────────────────────────────┘ │
└─────────────────────────────────────────────┘

Practical Defence Layers#

The OWASP Top 10 (2021)#

The Open Worldwide Application Security Project (OWASP) publishes a regularly updated list of the most critical web application security risks. The 2021 edition:

How to Use the OWASP Top 10#

The Top 10 is not a checklist — it is a risk awareness document. Use it to:

1. Prioritise — focus on the categories most relevant to your application
2. Educate — use it as a training tool for development teams
3. Audit — verify each category is addressed in your threat model
4. Benchmark — compare your controls against industry expectations

Threat Modelling#

Threat modelling is a structured process for identifying security risks before writing code.

STRIDE Model#

Practical Threat Modelling Steps#

1. Draw the system — data flow diagrams showing trust boundaries
2. Identify threats — apply STRIDE to each component crossing a trust boundary
3. Rate the risk — use DREAD or CVSS to prioritise
4. Mitigate — design controls for the highest-risk threats
5. Validate — test that mitigations actually work

Security Principles#

Principle of Least Privilege#

Grant each user, process, and service the minimum permissions required. A read-only API consumer should not have database write access. A Lambda function that reads from S3 should not have s3:*.

Fail Secure#

When a system fails, it should deny access rather than allow it. If the authentication service is unavailable, reject all requests — do not silently allow them through.

Zero Trust#

Never assume trust based on network location. Every request must be authenticated and authorised, whether it comes from the internet or from another service inside your VPC.

Traditional:  Internet ──[Firewall]──> Trusted Internal Network
Zero Trust:   Every service ──[AuthN + AuthZ]──> Every other service

Input Validation#

All input is untrusted until validated. This includes:

• Query parameters and form fields
• HTTP headers (including Host, Referer, X-Forwarded-For)
• File uploads (name, type, content)
• Data from your own database (it may have been injected earlier)

Security Headers Quick Reference#

A preview of headers covered in detail in later sections:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Content-Security-Policy: default-src 'self'; script-src 'self'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

Key Takeaways#

• The CIA triad (Confidentiality, Integrity, Availability) is the foundation of all security thinking — every control maps to one or more of these pillars.
• Attack surfaces include every point where data enters or leaves your system — URLs, headers, cookies, file uploads, WebSockets, and third-party integrations.
• Defence in depth layers multiple independent controls so that no single failure compromises the system.
• The OWASP Top 10 is a risk awareness framework, not a checklist — use it to prioritise, educate, and audit.
• Threat modelling (STRIDE) identifies security risks at design time, when they are cheapest to fix.
• Least privilege, fail secure, and zero trust are non-negotiable principles for any production system.