4.3Application security

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 .env via .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.