We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Security Architecture
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Security Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A developer wrote parameterized queries everywhere, except in one legacy admin endpoint that built strings through concatenation. An attacker found it, extracted the entire user database through blind SQL injection, and was in and out before anyone noticed. The application had proper defenses in most places, but one missed spot was enough.
The Heartland Payment Systems breach in 2008 followed a similar pattern. Attackers found a single SQL injection vulnerability in the payment processing application and stole 130 million credit card numbers. The total cost exceeded $200 million in fines, settlements, and remediation.
A WAF acts as a shield in front of your application, inspecting every request for known attack patterns before it reaches your code. Even if your application has a vulnerability you do not know about, the WAF can block the malicious request. It is not a replacement for secure code. It is an additional layer that catches what slipped through.
Operating modes:
| Mode | Behavior | Use Case |
|---|---|---|
| Detection (log only) | Log and alert, do not block | Initial deployment, tuning false positives, understanding traffic patterns |
| Prevention (block) | Block requests matching rules, return 403 | Production enforcement after tuning |
What a WAF inspects on every request:
| Request Part | Attack It Catches | Example Pattern |
|---|---|---|
| URL path | Path traversal | ../../etc/passwd, ..%2f..%2f (URL-encoded) |
| Query parameters | injection | ' OR 1=1--, UNION SELECT, '; DROP TABLE |
| Request body | XSS payloads | <script>alert('xss')</script>, onerror=alert(1) |
| Headers | Header injection, oversized headers | CRLF injection: \r\nSet-Cookie: stolen=true |
| Cookies | Session manipulation | Tampered , oversized cookie bombs |
| Content-Type | Content-type confusion | Sending XML when JSON expected to trigger XXE |
The OWASP Core Rule Set (CRS) is the standard open-source rule set. Version 4.0 detects the OWASP Top 10 attack types with over 200 rules. Most cloud WAFs include CRS or equivalent rules as a baseline.
WAF limitations you must understand:
False positives are the daily reality of running a WAF. A blog post containing SELECT * FROM triggers SQL injection rules. A user named O'Brien triggers single-quote detection. An API accepting HTML content triggers XSS rules. Run in detection mode for 2 to 4 weeks before enforcing. Whitelist known-good patterns. Expect to spend ongoing time tuning.
Bypass techniques are well-documented. Attackers use double encoding (%2527 instead of '), case mixing (SeLeCt), comment injection (SEL/**/ECT), and payloads split across multiple parameters. A WAF catches the 95% of attacks that use known patterns. The remaining 5% requires secure code.