Before Optional Lab 2.x — Application Gateway and WAF
Before Optional Lab 2.x — Application Gateway and WAF
In the core Day 2 labs, you restricted access to the internal backend and moved the data layer behind private endpoints.
The public backend API is still directly reachable from the internet with no inspection of the HTTP traffic itself.
This optional lab adds an Application Gateway with a Web Application Firewall (WAF) in front of the public backend.
What Application Gateway is
Azure Application Gateway is a regional Layer 7 load balancer.
It sits between the internet and your backend services. Every HTTP request passes through it before reaching the application.
Layer 7 means it understands HTTP. It can inspect the URL, headers, and body — not just the IP address and port.
What the WAF adds
The WAF (Web Application Firewall) is a component of Application Gateway that inspects HTTP requests against a ruleset.
The default ruleset is the OWASP Core Rule Set (CRS). It detects and blocks common attack patterns:
| Attack type | Example |
|---|---|
| SQL injection | ' OR 1=1 -- in a query parameter |
| Cross-site scripting (XSS) | <script> in a form field |
| Path traversal | ../../etc/passwd in a URL |
| Protocol violations | Malformed HTTP headers |
| Request size abuse | Oversized request bodies |
Without a WAF, these requests reach the application code. The application must defend itself. With a WAF, malicious requests are blocked before they reach the application.
WAF modes
| Mode | What it does |
|---|---|
| Detection | Logs matching requests but does not block them |
| Prevention | Blocks matching requests and returns 403 |
Detection mode is useful for tuning — you can see what would be blocked without affecting traffic. Prevention mode is the production setting.
In this lab, we use Prevention mode.
How this fits into the Day 2 architecture
After this lab, the architecture looks like this:
Every component is now protected at the appropriate layer:
| Component | Protection |
|---|---|
| Public Backend API | App Gateway WAF blocks malicious HTTP |
| Internal Backend Service | Access restriction — only reachable from public backend |
| DB Storage Account | Private endpoint — no public network access |
| Key Vault | Private endpoint — no public network access |
App Service access restriction after App Gateway
Once App Gateway is in place, the public backend App Service should only accept traffic from the App Gateway subnet — not directly from the internet.
This is the same pattern from Lab 2.3, applied one layer up:
Lab 2.3: internal backend only accepts traffic from public backend subnet.
This lab: public backend only accepts traffic from App Gateway subnet.After the restriction is in place:
Internet → Public Backend App Service URL = 403 Forbidden
Internet → App Gateway → Public Backend = worksWhat this lab does not cover
HTTPS on the listener. The App Gateway in this lab listens on HTTP port 80. In production, you would configure an HTTPS listener with a certificate from Key Vault. That adds certificate management complexity that is out of scope for this lab.
Custom WAF rules. The lab uses the default OWASP managed rule set. Production WAF deployments often add custom rules (rate limiting, geo-blocking, specific header requirements). Those are covered in Azure WAF documentation.
URL-based routing. Application Gateway can route different URL paths to different backends. This lab uses a single backend pool.
Check before starting
- What is the difference between a WAF and a network security group?
- What does OWASP stand for, and what does the CRS protect against?
- Why does the App Service still need an access restriction after App Gateway is deployed?