Application and data protection
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 2021 edition names these categories: 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 assess sanitization methods against the media, key lifecycle and applicable requirements. Cryptographic erasure depends on sound encryption, effective key destruction and control of all relevant key and data copies.
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.