What's changed: Initial version
4.3Application security
Covers secret management for handling credentials safely (environment variables/secret stores, never committing plaintext) and encryption (at rest and in transit), the roles of the firewall, DNS, load balancer, and reverse proxy, and the representative OWASP threats (XSS, SQLi, CSRF)—framed as diagnosing "what this handling protects and where the hole is."
App security is less about "adding features" than about not creating holes. Hardcoding an API key into source and pushing it to git lets anyone who reads the code touch production. Encryption is not "safe once applied" either—you cannot protect what you cannot distinguish as at rest versus in transit. This section covers secret handling, encryption, the boundary infrastructure parts (firewall/DNS/LB/reverse proxy), and the representative OWASP threats from the viewpoint of diagnosing "what this handling protects and where the hole is."
4.3.1Secret management and data encryption
- Secrets are API keys, passwords, tokens, private keys, and the like. Hardcoding them into source and committing to version control is taboo (they persist in history and are exploited the moment they are published/leaked). Instead, read them at runtime from environment variables or a dedicated secret store/vault, and keep them out of the repo (exclude
.envvia.gitignore). - Encryption splits by what it protects: encryption at rest encrypts data on disk/DB, protecting against media theft or unauthorized copying. Encryption in transit uses TLS/HTTPS to encrypt the communication path, protecting against eavesdropping/tampering. Both are needed, and one cannot substitute for the other—"the DB is safe because we use HTTPS" is false.
- For data handling, follow principles like collecting/keeping no more than necessary (minimization), protecting according to the classification handled (PII/confidential), and not leaking secrets or PII into logs or notifications (do not log a token verbatim). Most leaks come not from sophisticated attacks but from plaintext left lying around.
4.3.2Boundary infrastructure parts
- A firewall is the boundary gatekeeper that permits/denies traffic by policy. DNS resolves a name (
api.example.com) to an IP; it is not itself a defense device, but if name resolution fails the app cannot reach its peer (a key point in connectivity diagnosis). - A load balancer (LB) distributes incoming requests across multiple backends to ensure availability and scale (if one node dies, the rest keep serving). A reverse proxy stands between clients and backends, handling TLS termination, caching, routing, and backend concealment. LB and reverse proxy roles can overlap, but judge by whether "distribution" or "mediation/termination" is the main aim.
4.3.3Representative OWASP threats
- XSS (cross-site scripting) runs an attacker's script in another user's browser. The cause is outputting user input into HTML without sanitizing. The countermeasure is output escaping and input validation (e.g., neutralizing
<script>). - SQLi (SQL injection) occurs when user input is embedded into a query by string concatenation, so input like
' OR '1'='1can hijack the DB. The countermeasure is a parameterized query (prepared statement) that treats input as a value, not as SQL syntax. - CSRF (cross-site request forgery) makes a logged-in user's browser send an unintended state-changing request (transfer, settings change, etc.) via a third-party site. The countermeasure is a CSRF token (accept only requests originating from a legitimate form) or SameSite cookies.
Most-tested: read secrets at runtime from env vars/vault, never commit them in source; distinguish encryption at rest from in transit (TLS/HTTPS)—both are needed and neither substitutes for the other; LB = distribution for availability/scale, reverse proxy = TLS termination/mediation/concealment; XSS = output escaping, SQLi = parameterized query, CSRF = CSRF token. Questions come as diagnosing where this handling/code has a hole.
Suppose you are reviewing a Python API client written by a new hire. At the top, API_KEY = "sk_live_9f2c...a real production key" is hardcoded and pushed straight to the repo. This is the most basic and most dangerous hole. The production key lives forever in git history, and everyone who can view the repo (contractors, departed staff, the whole world if it goes public) can operate production with that key. The correct fix is to take the key out of the code and read it from an environment variable (e.g., os.environ["API_KEY"] at runtime) or a secret store, add .env to .gitignore to keep it out of the repo, and invalidate and reissue (rotate) any key already pushed (merely scrubbing history does not undo a possible leak). Next, the app's data-protection policy states "communication is HTTPS, so DB encryption is unnecessary." This confuses at rest with in transit. Encryption in transit (TLS/HTTPS) prevents on-path eavesdropping, but it is powerless when the server disk or a DB backup is stolen—that is guarded by encryption at rest. The two protect different things, and neither substitutes for the other. Further, the input handling embeds the username into a query by string concatenation: "SELECT * FROM users WHERE name = '" + name + "'". This is a classic SQLi hole—input like ' OR '1'='1 leaks every row. The fix is a parameterized query so input is treated as a value. The lesson: app security is less about advanced cryptographic theory than about the judgment to spot and plug basic holes—"do not commit secrets in plaintext," "know whether encryption guards at rest or in transit," "do not let input be interpreted as syntax"—from the presented code.
| Threat | What happens | Primary cause | Primary countermeasure |
|---|---|---|---|
| XSS | Malicious script runs in another user's browser | Output input into HTML without sanitizing | Output escaping, input validation |
| SQLi | DB data leak/tamper/takeover | Embed input into a query via concatenation | Parameterized queries |
| CSRF | Force an unintended state-changing request | Not verifying a request's legitimate origin | CSRF token, SameSite cookies |
Trap: "As long as communication is HTTPS, the DB's stored data is safe even without encryption" is wrong—encryption in transit only prevents on-path eavesdropping, and disk/backup theft requires separate encryption at rest. Also wrong: "hardcoding a secret in source is fine if you scrub it from git history later"—a key once pushed must be treated as leaked and invalidated/reissued (rotated), and history deletion alone does not protect you.
4.3.4Section summary
- Read secrets at runtime from env vars/vault, never hardcode and commit them; invalidate and reissue leaked keys
- Encryption distinguishes at rest from in transit (TLS/HTTPS) and needs both—neither substitutes for the other
- OWASP: plug XSS with output escaping, SQLi with parameterized queries, CSRF with a CSRF token; LB = distribution, reverse proxy = TLS termination/mediation
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. In code review you find a production API key hardcoded as `API_KEY = "sk_live_..."` at the top of a Python script and pushed straight to the repo. Which remediation is most appropriate?
Q2. A team decides "since we moved communication to HTTPS, data stored in the database need not be encrypted." Which assessment of this decision is most appropriate?
Q3. An endpoint embeds user input `name` into a query by string concatenation like `"SELECT * FROM users WHERE name = '" + name + "'"`, so input like `' OR '1'='1` returns every row. Which is the most appropriate root-cause fix?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.