Application and Data Security
This domain covers how applications fail and how data is classified and protected through its life. Questions often present a code behaviour or a data-handling scenario and ask for the correct control.
Secure development
Security belongs in the SDLC: threat modelling at design, secure coding standards, code review, SAST/DAST in the pipeline, dependency scanning for vulnerable components, and security testing before release. The OWASP Top 10 remains the standard vocabulary: broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable and outdated components, identification and authentication failures, software and data integrity failures, logging and monitoring failures, and SSRF.
Defences that actually work
- Parameterised queries or prepared statements against SQL injection; never string concatenation.
- Context-aware output encoding against XSS, plus Content-Security-Policy.
- Anti-CSRF tokens and SameSite cookies.
- Server-side authorisation checks on every request; never rely on hidden fields or client-side validation.
- Session management: rotate the session ID at login, use HttpOnly and Secure cookies, enforce idle timeout.
- Secrets in a vault, never in source code or build logs.
Data security
Classify data (public, internal, confidential, restricted) and apply handling rules per class: encryption at rest and in transit, masking in test and analytics environments, DLP at egress, retention limits and secure disposal. Minimisation reduces the blast radius of any breach, and crypto-shredding is an accepted disposal method for encrypted stores.
Worked example
A login form builds SELECT * FROM users WHERE name='$user'. An attacker submits ' OR '1'='1. The fix is a prepared statement with bound parameters, plus input validation as defence in depth, plus a least-privilege database account so a successful injection still cannot read other schemas.
Traps
- Confusing XSS (injected script runs in the victim's browser) with CSRF (the browser sends an unwanted authenticated request).
- Encoding for the wrong context - HTML encoding does not protect a JavaScript string or a URL.
- Leaving sensitive data in logs, caches or test copies that were never classified.