Application and Systems Security
Application and systems security covers how software defects, weak configurations, and unsafe deployment choices become exploitable weaknesses. The DSST exam tests whether you can map a scenario to the right control, distinguish prevention from detection, and explain why a familiar-sounding fix fails.
Core rules
- Validate input on the server, using allowlists that define permitted characters, lengths, formats, and ranges; client-side checks are usability aids, not controls.
- Encode output for its destination (HTML, attribute, JavaScript, SQL, OS command, LDAP) so data is never interpreted as code.
- Use parameterized queries or prepared statements for database access; never concatenate untrusted strings into SQL.
- Apply least privilege to application accounts, service identities, database roles, and file permissions. A web app should not connect as a database administrator.
- Fail securely: deny by default, handle errors without leaking stack traces or secrets, and keep security checks on the server.
- Harden the platform: remove unused services and accounts, change default credentials, restrict administrative interfaces, patch dependencies, and log security events.
- In the SDLC, shift security left with threat modeling, secure design review, SAST, dependency scanning, DAST, and code review; security testing is not a single pre-release gate.
OWASP Top 10 categories worth recognizing include 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 server-side request forgery. Memory aid: defects cluster around who can do what (access control), what data is trusted (injection/integrity), and what is visible after failure (logging).
Worked example
A login form builds the query SELECT * FROM users WHERE email = '$email' AND password_hash = '$hash'. An attacker submits an email containing ' OR '1'='1' --. The fix is not 'escape quotes'; it is to bind email and hash as parameters, compare the supplied password against a stored slow hash (bcrypt, scrypt, Argon2) inside the application, and run the query under a role that can read only the users table. Reasoning: the root cause is mixing code and data, and least privilege limits damage if validation fails.
Traps that cost marks
Equating HTTPS with injection prevention; treating authentication as authorization; relying on blacklists instead of allowlists; assuming a WAF removes the need to fix code; confusing hashing (one-way, for passwords) with encryption (reversible, for confidentiality); forgetting that container images and third-party libraries are part of the attack surface.