Application and Data Security
Domain 4 covers building software that resists attack and protecting the data it handles. L1 items give a code snippet, a request pattern or a data-handling scenario and ask for the flaw or the correct control.
Secure development basics
Security belongs in every phase: requirements, design threat modelling, coding standards, testing, and deployment. The recurring rules:
- Validate input on the server with an allow-list of expected format; client-side checks are convenience only and are trivially bypassed.
- Use parameterized queries or prepared statements for every database call; never concatenate user input into SQL.
- Encode output according to context (HTML, attribute, JavaScript, URL) to stop cross-site scripting.
- Enforce authorization on the server for every object request, since hiding a menu item does not stop a direct request for another user's record.
- Manage sessions with random identifiers, HttpOnly and Secure cookie flags, logout invalidation and sensible timeouts.
The OWASP Top 10 is the standard checklist: broken access control, cryptographic failures, injection, insecure design, misconfiguration, vulnerable components, authentication failures, data integrity failures, logging failures, and server-side request forgery.
Data protection
Classify data (public, internal, sensitive, confidential), then apply matching controls: encryption in transit with TLS and at rest on disk or in the database, masking in test environments, DLP on egress points, defined retention and secure deletion. Backups follow 3-2-1: three copies, two media types, one offline or off-site, with restore tests. Hashing is not encryption - a hash is one-way and cannot be reversed.
Worked example
A login form submits the name field; entering ' OR '1'='1 returns the first user record and logs in as an administrator.
Reasoning: the input changed the SQL statement's logic, so the query is assembled by string concatenation - a SQL injection against integrity and confidentiality. The fix is parameterized queries, plus a least-privilege database account so a successful injection cannot read other schemas. A WAF is a compensating control that buys time; it is not the fix, because the vulnerable code remains.
Traps that cost marks
- Relying on client-side validation or hidden fields for security.
- Confusing escaping with encoding, or applying the wrong output context.
- Treating encryption as a substitute for access control.
- Keeping backups on the same host, where ransomware encrypts them too.