Application and Data Security
Secure development and the common flaw classes
Application security starts in the SDLC: threat modeling, secure coding standards, code review, SAST/DAST, and secure deployment. The recurring flaw families are injection (SQL, command, LDAP), broken authentication and session management, cross-site scripting (stored, reflected, DOM), cross-site request forgery, insecure direct object references and broken access control, security misconfiguration, sensitive data exposure, insecure deserialization, and vulnerable components.
Defenses are specific, not generic: parameterized queries/prepared statements stop SQL injection; input validation plus output encoding stop XSS; anti-CSRF tokens and SameSite cookies stop CSRF; server-side authorization checks stop IDOR; TLS with strong ciphers protects data in transit; encryption at rest plus key management protects stored data. Know the crypto primitives - symmetric (AES) for bulk data, asymmetric (RSA/ECC) for key exchange and signatures, hashing (SHA-256) for integrity, HMAC for authenticated integrity, digital signatures for non-repudiation, salt for password storage, and KDFs such as bcrypt/PBKDF2/Argon2 for passwords.
Data security
Classify data, apply handling rules, use DLP to enforce them, encrypt at rest and in transit, tokenize or mask sensitive fields, and control database access with least privilege and auditing.
Traps
Hashing is one-way and provides integrity, not confidentiality; encoding is not encryption; salting does not make hashing reversible. XSS attacks the user's browser through the site; CSRF abuses the user's existing authenticated session. Validation happens on the server even when the client also validates.
Rule of thumb
For any input-handling question, choose the control that removes the vulnerability class at its source (parameterization, encoding, server-side authorization) before choosing a detective control such as a WAF.