Module 01 — Web Application Security Fundamentals & Zero Trust¶

Cloud Security & the Shared Responsibility Model¶

When an organization moves workloads to the cloud, security responsibilities are shared between the cloud provider and the customer. The exact split depends on the service model — Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS). Misunderstanding these boundaries is one of the most common causes of cloud security incidents.

Microsoft secures the physical infrastructure, the host operating system, and the hypervisor layer across all service models. Customers are always responsible for their data, identities, and endpoint devices. Everything in between shifts depending on the service model you choose.

Responsibility Matrix¶

The following table summarizes who is responsible for each layer across service models:

What Does This Mean in Practice?¶

Consider a web application running on Azure App Service (PaaS). Microsoft manages the underlying VM, the operating system patches, and the runtime. But the application code, the authentication logic, and the data in the database are entirely your responsibility. If an attacker exploits a SQL injection vulnerability in your code, Microsoft's platform security cannot help — the attack is inside your responsibility boundary.

This is exactly where Azure WAF enters the picture.

Where Does Azure WAF Fit?¶

Azure WAF is a customer-managed control that operates at Layer 7 (the application layer). Whether you run your workloads on IaaS virtual machines, PaaS App Services, or containerized microservices, protecting the HTTP/HTTPS entry point is always the customer's responsibility. Azure WAF lets you fulfill that responsibility with a managed, cloud-native service instead of deploying and maintaining your own WAF appliances.

Zero Trust Architecture¶

The End of the Perimeter¶

Traditional network security relied on a clear perimeter: a firewall at the edge, a trusted internal network, and an untrusted internet. In a cloud-first, mobile-first world that model breaks down. Users connect from anywhere on any device, applications span multiple clouds and SaaS services, and APIs expose data far beyond the corporate network.

The traditional model assumed that anything inside the firewall was safe. Attackers exploited this assumption repeatedly — once inside the perimeter (through phishing, stolen VPN credentials, or a compromised endpoint), they moved laterally with little resistance.

Zero Trust replaces the concept of a trusted network with the principle of "never trust, always verify." Every request — regardless of origin — is authenticated, authorized, and continuously validated before access is granted.

The Three Pillars¶

Microsoft's Zero Trust framework rests on three core principles. Understanding these principles is essential because Azure WAF directly implements aspects of each one.

1. Verify Explicitly¶

Always authenticate and authorize based on all available data points: user identity, device health, location, service or workload, data classification, and anomaly signals. Multi-factor authentication, conditional access policies, and risk-based sign-in are concrete implementations of this principle.

Real-world example: A developer requests access to a production App Service. Azure AD Conditional Access verifies that the request comes from a compliant device, a known IP range, and a low-risk session before issuing a token — even though the developer is "inside" the corporate VPN. If any signal is abnormal, access is denied or stepped-up authentication is required.

How Azure WAF contributes: WAF inspects every HTTP/HTTPS request against managed and custom rules before forwarding it to the backend. This is explicit verification at the application layer — no request is trusted simply because it arrived at the correct URL.

2. Use Least Privilege Access¶

Limit every identity — human or workload — to the minimum permissions required to perform its task, and only for the time needed. Just-In-Time (JIT) access, Just-Enough-Administration (JEA), and risk-based adaptive policies enforce this principle at the identity layer.

Real-world example: An SRE needs to update a WAF exclusion in production. Instead of granting permanent Contributor rights, Azure PIM (Privileged Identity Management) grants WAF Policy Contributor for a two-hour window, with approval from a security lead. After two hours the elevation expires automatically.

How Azure WAF contributes: Custom rules can restrict access by geography, IP range, HTTP method, or request header, ensuring that only expected traffic patterns reach the application. For example, a rule might allow POST /api/admin only from your corporate IP range.

3. Assume Breach¶

Design every system as if an attacker is already inside the network. Minimize the blast radius through micro-segmentation, encrypt data end-to-end, and use analytics to detect lateral movement and persistence.

Real-world example: Even after a request passes Azure WAF, the backend App Service enforces authentication via Easy Auth, validates a JWT token, and applies row-level security in the database. If the WAF is somehow bypassed through a zero-day, multiple additional controls limit the damage.

How Azure WAF contributes: WAF logs feed into Microsoft Sentinel, enabling automated threat detection and response. If an attacker exploits a vulnerability, WAF telemetry accelerates incident investigation and provides the forensic trail needed for root-cause analysis.

Zero Trust Architecture Diagram¶

Architecture diagram showing how Azure WAF fits into a Zero Trust security model — from edge protection (DDoS + Front Door WAF) through network controls (Firewall + App Gateway WAF) to application-tier validation (Entra ID + encrypted data), with all WAF logs flowing to Log Analytics and Microsoft Sentinel for continuous monitoring.

How Azure WAF Enables Zero Trust — Summary¶

Modern Web Application Threat Landscape¶

Web applications are the primary attack surface for most organizations. According to the Verizon Data Breach Investigations Report, over 80 % of breaches involve the application layer. The attack landscape continues to evolve with API-first architectures, bot automation, supply-chain compromises, and AI-powered exploitation.

Understanding the most common attack categories is essential before configuring WAF rules — it helps you prioritize which rule groups to enable, which thresholds to set, and where custom rules are needed.

OWASP Top 10 (2021)¶

The Open Worldwide Application Security Project (OWASP) publishes a regularly updated list of the ten most critical web application security risks. The 2021 edition — still the current reference as of 2026 — reshuffled several categories and introduced new ones based on data from hundreds of organizations.

A01 — Broken Access Control¶

Broken access control moved to the #1 position in 2021, up from #5 in 2017. It occurs when an application fails to enforce policies so that users can act outside their intended permissions. Examples include insecure direct object references (IDOR), missing function-level access control, CORS misconfigurations, and forced browsing to admin pages.

Attack scenario: An attacker changes accountId=1234 to accountId=5678 in a REST API URL and retrieves another user's data because the backend never validates ownership of the requested resource.

A02 — Cryptographic Failures¶

Previously called Sensitive Data Exposure, this category covers failures related to cryptography — or the complete lack of it. Transmitting data in cleartext, using deprecated algorithms (MD5, SHA-1 for password hashing), weak key management, and missing HSTS headers all fall here.

Attack scenario: A health-care portal transmits patient records over HTTP instead of HTTPS between the load balancer and the backend. An attacker on the same network segment captures PHI (Protected Health Information) via a man-in-the-middle attack.

A03 — Injection¶

Injection flaws — SQL injection, NoSQL injection, OS command injection, LDAP injection, and expression language injection — occur when untrusted data is sent to an interpreter as part of a command or query. Despite decades of awareness, injection remains extremely common because developers continue to concatenate user input into queries.

Attack scenario: An attacker submits ' OR 1=1 -- in a login form. The backend concatenates the input into a SQL query, bypassing authentication entirely and returning all user records.

-- Vulnerable query (never do this)
SELECT * FROM users WHERE username = '' OR 1=1 --' AND password = '...';

A04 — Insecure Design¶

A new category in 2021, insecure design highlights the need for threat modeling and secure design patterns before code is written. No amount of WAF rules can fix a fundamentally insecure architecture — for example, an API that returns full user profiles including password hashes because the data model was never reviewed for information exposure.

A05 — Security Misconfiguration¶

Default credentials, unnecessary open ports, overly verbose error messages, missing security headers (CSP, X-Frame-Options), and permissive CORS configurations are all examples of security misconfiguration. This is one of the most common issues found in cloud environments because of the speed at which resources are provisioned.

Attack scenario: An Azure App Service is deployed with detailed error pages enabled in production, leaking stack traces, connection strings, and internal IP addresses to anyone who triggers a server error.

A06 — Vulnerable and Outdated Components¶

Using libraries, frameworks, or OS packages with known vulnerabilities is a persistent risk. Supply-chain attacks — such as compromised npm packages or malicious Python wheels — exploit this category. High-profile examples include Log4Shell (CVE-2021-44228) and the event-stream incident.

A07 — Identification and Authentication Failures¶

Weak passwords, missing brute-force protection, improper session management, and credential stuffing attacks allow adversaries to compromise user identities. Credential-stuffing bots use leaked password databases to automate login attempts at massive scale.

Attack scenario: An attacker uses a list of 10 million stolen email/password pairs to submit automated login requests against your application at a rate of 1,000 requests per second. Without rate limiting, the application processes every attempt.

A08 — Software and Data Integrity Failures¶

This category covers code and infrastructure that does not protect against integrity violations — for example, auto-updating dependencies without verification, CI/CD pipelines without artifact signing, or deserialization of untrusted data. The SolarWinds supply-chain attack is a prominent example.

A09 — Security Logging and Monitoring Failures¶

Without adequate logging, attackers can persist undetected for months. The median time to detect a breach is still measured in hundreds of days. Azure WAF diagnostic logs, when forwarded to a Log Analytics workspace and analyzed by Microsoft Sentinel, provide the visibility needed to detect and respond to application-layer attacks in near real time.

A10 — Server-Side Request Forgery (SSRF)¶

SSRF occurs when an application fetches a remote resource without validating the user-supplied URL. Attackers can abuse this to access internal services, cloud metadata endpoints, or internal APIs that are not exposed to the internet.

Attack scenario: An attacker submits http://169.254.169.254/metadata/identity/oauth2/token as an image URL. The application fetches the URL server-side and returns the Azure Instance Metadata Service (IMDS) token, which the attacker uses to escalate privileges.

OWASP Top 10 Summary Table¶

Why WAF Matters¶

The Cost of Doing Nothing¶

Application-layer attacks are not abstract risks — they have concrete financial, legal, and reputational consequences that affect organizations of every size:

• Average cost of a data breach (IBM Cost of a Data Breach Report, 2024): $4.88 million globally, $9.36 million in the United States.
• Time to identify and contain a breach: 258 days on average — nearly nine months of undetected attacker activity.
• Web application attacks account for the majority of breach vectors involving external actors according to the Verizon DBIR.
• Ransomware increasingly begins with web application exploitation — attackers establish a foothold through a web vulnerability and then deploy ransomware across the internal network.

A properly configured WAF dramatically reduces the attack surface, blocks known exploit patterns automatically, and provides early warning signals through logging that cut detection time from months to minutes.

Regulatory Drivers¶

Many compliance frameworks explicitly require or strongly recommend web application firewalls for public-facing applications:

Application-Layer Attack Statistics¶

To put these risks in perspective, consider the following data points from recent industry reports:

• 43 % of all cyber-attacks target web applications (Akamai State of the Internet report).
• SQL injection remains the most weaponized attack vector for web applications, despite being well-understood for over two decades.
• Bot traffic accounts for approximately 30 % of all web traffic, with malicious bots making up nearly half of that share.
• The average enterprise exposes over 300 web applications to the internet, each representing a potential attack surface.
• API attacks increased by over 400 % year-over-year as organizations adopt API-first architectures without adequate security controls.

These statistics underscore why a centralized, managed WAF is no longer optional for organizations with public-facing web workloads — it is a foundational security control.

Defense in Depth¶

Defense in depth is a security strategy that layers multiple independent controls so that the failure of any single control does not result in a complete compromise. The concept originates from military strategy and has been a core security principle for decades. In cloud security, it means deploying controls at every layer of the stack.

The Layered Model¶

Azure provides security services at every layer. The following diagram illustrates the six primary layers and where Azure WAF fits:

block-beta
    columns 1
    A["🏢 Physical Security — Microsoft-managed datacenters, biometric access, 24/7 surveillance"]
    B["🌐 Network Security — NSG, Azure Firewall, DDoS Protection, Private Link, Service Endpoints"]
    C["🔒 Transport Security — TLS 1.3 termination, mutual TLS (mTLS), certificate management"]
    D["🛡️ Application Security — Azure WAF: Layer 7 inspection, OWASP rules, bot protection, rate limiting"]
    E["👤 Identity Security — Microsoft Entra ID, Conditional Access, MFA, PIM, workload identities"]
    F["💾 Data Security — Encryption at rest (SSE, CMK), Azure Key Vault, Microsoft Purview, row-level security"]

    style D fill:#0078d4,color:#fff

Each layer addresses a different class of threat:

• Physical security prevents unauthorized physical access to datacenters.
• Network security stops volumetric DDoS attacks, unauthorized port scans, and lateral movement between VNets.
• Transport security ensures data confidentiality and integrity in transit.
• Application security (where Azure WAF operates) inspects the actual HTTP request content to block injection attempts, bot traffic, and business-logic abuse.
• Identity security verifies that every user and workload is authenticated and authorized.
• Data security protects data at rest and provides fine-grained access control at the data layer.

Where Azure WAF Sits in the Stack¶

Azure WAF operates between the transport and application layers. It terminates TLS (or receives already-decrypted traffic from Application Gateway / Front Door) and inspects every attribute of the HTTP request:

Defense-in-Depth Request Flow¶

The following diagram shows how a typical request traverses multiple security layers before reaching the application:

sequenceDiagram
    participant Client
    participant DDoS as Azure DDoS Protection
    participant FD as Azure Front Door
    participant WAF as Azure WAF Policy
    participant AppGW as Application Gateway
    participant App as Web Application
    participant DB as Database

    Client->>DDoS: HTTPS Request
    DDoS->>FD: Volumetric check passed
    FD->>WAF: Route to WAF policy
    WAF->>WAF: Inspect headers, URI, body, cookies
    alt Request is malicious
        WAF-->>Client: 403 Forbidden (blocked)
    else Request is clean
        WAF->>AppGW: Forward to backend pool
        AppGW->>App: Deliver request
        App->>DB: Authenticated, parameterized query
        DB-->>App: Result set
        App-->>Client: 200 OK
    end

Each component in the chain is independent. Even if an attacker finds a way past the WAF (for example, through a zero-day vulnerability that has not yet been patched in the rule set), the application still validates the JWT token, the database enforces parameterized queries, and Sentinel detects anomalous behavior in the WAF logs. No single control is relied upon exclusively — that is the essence of defense in depth.

WAF Does Not Replace Secure Coding¶

It is critical to understand that Azure WAF is a mitigation layer, not a cure. WAF rules are pattern-based — they detect known attack signatures and anomalous request patterns. A sufficiently creative attacker may craft a payload that evades pattern detection. Therefore:

• Always use parameterized queries (prepared statements) instead of string concatenation.
• Always encode output appropriately for the rendering context (HTML, JavaScript, URL).
• Always enforce authorization checks in your application code, not just at the WAF level.
• Always keep dependencies updated to patch known vulnerabilities.
• Always implement Content Security Policy (CSP) headers to mitigate XSS execution.

WAF provides an essential first line of defense — but it works best as part of a comprehensive secure development lifecycle (SDL).

Practical Exercise — Identifying Attack Vectors¶

Before moving on to Module 02, consider the following scenario and think about which OWASP categories apply and where WAF could help.

Key Takeaways¶

References¶

• Shared Responsibility in the Cloud — Microsoft Learn
• Zero Trust Architecture — Microsoft Learn
• OWASP Top 10 — 2021
• OWASP API Security Top 10
• Cost of a Data Breach Report — IBM
• Verizon Data Breach Investigations Report
• Azure WAF and PCI-DSS — Microsoft Learn
• Defense in Depth — Microsoft Learn
• Microsoft Threat Intelligence Center (MSTIC)