Skip to main content
System Design – Complete Beginner to Advanced Guide
CHAPTER 16 Intermediate

System Design Security

Updated: May 16, 2026
30 min read

# CHAPTER 16

System Design Security

1. Introduction

A perfectly scaled, infinitely available system is useless if a teenager with a laptop can download your entire user database or crash your servers for fun. In distributed system design, security cannot be an afterthought bolted on at the end; it must be baked into the very architecture of the network. The perimeter of your application is constantly under attack by automated bots searching for vulnerabilities, brute-forcing passwords, and launching volumetric traffic floods. In this chapter, we will master System Design Security. We will architect defenses against Distributed Denial of Service (DDoS) attacks, deploy Web Application Firewalls (WAF) to block SQL Injection, and enforce strict encryption policies for data in transit and data at rest.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Architect defensive perimeters against DDoS attacks.
  • Deploy a Web Application Firewall (WAF) to neutralize malicious payloads.
  • Understand the mechanical difference between Encryption in Transit (HTTPS) and Encryption at Rest.
  • Prevent systemic vulnerabilities like SQL Injection and Cross-Site Scripting (XSS).
  • Implement the "Principle of Least Privilege" in cloud infrastructure.

3. DDoS Attacks and Defense Architecture

A Distributed Denial of Service (DDoS) attack is an attempt to make your system unavailable by overwhelming it with an infinite flood of fake traffic from a global botnet of hijacked computers.
  • The Vulnerability: If you have 5 Web Servers, a botnet sending 1 million requests per second will instantly exhaust your server CPU, database connections, and network bandwidth. The system crashes.
  • The Defense (The Cloud Shield): You cannot absorb a massive DDoS attack yourself. You must use a global mitigation provider (like Cloudflare or AWS Shield).
  • The Architecture: You change your DNS records so that *all* traffic must flow through Cloudflare's massive global network first. Cloudflare acts as a sponge, utilizing advanced algorithms to detect and drop the fake bot traffic at the Edge, allowing only the legitimate human traffic to pass through to your fragile internal servers.

4. Web Application Firewalls (WAF)

While a DDoS attack tries to crush your server with volume, Application-Layer attacks (like SQL Injection) try to trick your server with malicious logic.
  • The Attack (SQL Injection): A hacker types " OR 1=1; DROP TABLE Users; -- into your login box. If your backend code does not sanitize this input, the database will literally execute the command and delete your entire user table.
  • The WAF Defense: You deploy a WAF at your Load Balancer or API Gateway. The WAF inspects the actual HTTP body of every incoming request. If it sees suspicious code patterns (like SQL commands or malicious JavaScript), it blocks the request with an HTTP 403 Forbidden before it ever touches your backend servers.

5. Encryption (In Transit vs. At Rest)

Data is vulnerable when it is moving, and when it is sitting still. You must encrypt both.
  • Encryption in Transit (HTTPS/TLS): When a user submits their credit card, the data travels across public Wi-Fi routers and ISP hubs. TLS mathematically encrypts the data so anyone intercepting the signal just sees gibberish. As discussed in Chapter 6, the Load Balancer handles the "SSL Termination" (decryption).
  • Encryption at Rest: If a physical hard drive is stolen from an AWS data center, or if an S3 bucket is compromised, the raw data files should be unreadable. You architect the system so the Database and Object Storage automatically encrypt the files on the hard disk using KMS (Key Management Service).

6. The Principle of Least Privilege

The most dangerous threat is often inside your own architecture.
  • The Anti-Pattern: A developer gives the Image Processing Microservice full Admin access to the entire AWS cloud so they don't have to worry about permission errors.
  • The Disaster: A hacker finds a vulnerability in the Image Microservice. Because the service has Admin access, the hacker uses it to delete the entire production database.
  • The Principle: Every microservice, every database, and every human should have the absolute minimum permissions required to do their specific job, and nothing more. The Image service should *only* have "Write" access to the specific "Images" S3 bucket.

7. Diagrams/Visual Suggestions

*Architecture Diagram: The Defense in Depth Perimeter*
text
12345 
[ Global Botnet ] --(1M Req/Sec)--> [ CLOUDFLARE (Absorbs DDoS) ]
                                            |
[ Malicious Hacker ] --(SQL Injection)--> [ WAF (Blocks Payload) ]
                                            |
[ Legitimate User ] --(Clean HTTPS)-----> [ API GATEWAY ] --> [ Web Servers ]

8. Best Practices

  • VPC (Virtual Private Cloud): Never expose your databases or backend microservices to the public internet. They should live in private subnets with no public IP addresses. The only component with a public IP address should be your Load Balancer/API Gateway. If a hacker tries to directly ping your database, the network physically drops the connection.

9. Common Mistakes

  • Hardcoding Secrets: A junior developer hardcodes the Stripe API Secret Key or the Database Password directly into the Node.js source code, and commits it to a public GitHub repository. *The Failure:* Automated bots scrape GitHub 24/7. Within 3 seconds, the key is stolen, and thousands of dollars are charged. *The Fix:* Never hardcode secrets. Use environment variables (.env) or specialized secret managers like AWS Secrets Manager or HashiCorp Vault, injecting the secrets into the app only at runtime.

10. Mini Project: Secure a Web Application

Let's build a fortress around a fragile API.
  1. 1. The Perimeter: We route the domain through Cloudflare to absorb volumetric DDoS attacks.
  1. 2. The Gateway: We configure the AWS API Gateway WAF to automatically block requests containing SQL syntax or Cross-Site Scripting (XSS) payloads.
  1. 3. The Network: We place the PostgreSQL database in a Private VPC Subnet. It accepts traffic *only* from the internal IP addresses of the Web Servers.
  1. 4. The Code: We configure the Web Servers to connect to the database using short-lived, dynamically generated credentials pulled from AWS Secrets Manager.
*Result:* A secure, defense-in-depth architecture that assumes failure at every layer.

11. Practice Exercises

  1. 1. Define a Distributed Denial of Service (DDoS) attack. Why is it architecturally impossible for a standard web server to defend itself against a massive volumetric DDoS attack, and what external infrastructure must be used?
  1. 2. Explain the difference between "Encryption in Transit" and "Encryption at Rest." At what points in the network architecture are these encryptions applied and decrypted?

12. MCQs with Answers

Question 1

A hacker discovers a vulnerability in an e-commerce website and types malicious database commands into the Search Bar. If the backend code does not sanitize this input, the database might execute the commands, allowing the hacker to steal user data. What specialized architectural security component should be deployed at the perimeter to inspect HTTP payloads and automatically block this "SQL Injection" attack?

Question 2

When architecting the network layout of a cloud environment (like AWS or GCP), it is a critical security mandate that the primary databases and internal microservices are placed inside a "Private Subnet." What does this mean?

13. Interview Questions

  • Q: Explain the "Principle of Least Privilege." How does applying this principle strictly to IAM (Identity and Access Management) roles for your microservices prevent a single compromised server from destroying the entire cloud infrastructure?
  • Q: Walk me through the mechanics of a volumetric DDoS attack. If a botnet is blasting your servers with 100 gigabits of traffic per second, explain how global mitigation networks (like Cloudflare) act as a sponge to protect your origin servers.
  • Q: A junior engineer commits an API key to a public GitHub repository. What is the immediate architectural failure, and what enterprise systems (like HashiCorp Vault) should be implemented to manage and inject secrets securely into applications at runtime?

14. FAQs

Q: Does HTTPS (Encryption in Transit) protect against XSS or SQL Injection? A: No. HTTPS only protects the data as it travels across the network wire, preventing someone from listening in (a Man-in-the-Middle attack). It encrypts the *payload*. However, if the payload itself contains a malicious SQL Injection command, the server will decrypt it and execute the malicious command. HTTPS does not protect against bad logic.

15. Summary

In Chapter 16, we fortified the architecture. We acknowledged that the public internet is a hostile environment. We built a "Defense in Depth" strategy, understanding that no single layer of security is impenetrable. We deployed global shields to absorb volumetric DDoS attacks, and configured Web Application Firewalls to surgically intercept malicious payloads like SQL Injections. We secured our data's journey with HTTPS encryption, and locked it safely on disk with Encryption at Rest. By enforcing Private VPC subnets and the strict Principle of Least Privilege, we ensured that even if the outer walls are breached, the core infrastructure remains resilient and secure.

16. Next Chapter Recommendation

The system is designed, scaled, and secured. But how do we physically deploy all this code to the cloud without breaking it? Proceed to Chapter 17: Cloud Architecture and DevOps.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Previous Chapter Real-Time Systems Design
Next Chapter Cloud Architecture and DevOps

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·

Explore More

📖 Related Tutorials 5

🎥 Related Videos 1