Secure Coding and Application Mitigations
Key Takeaways
- Secure coding reduces vulnerabilities before deployment through design review, input handling, output encoding, authentication, and authorization.
- Parameterized queries, allow-list validation, output encoding, and safe error handling address common web application risks.
- Code review, SAST, DAST, SCA, fuzzing, and secrets scanning find different classes of weaknesses.
- Application mitigations should be placed as close as possible to the root cause; WAF and RASP are useful but often compensating controls.
- Secure SDLC practices include threat modeling, security requirements, testing gates, and dependency governance.
Last updated: April 2026
Secure Coding and Application Mitigations
Secure coding questions usually ask for the control that prevents a vulnerability class rather than only detecting attacks after release.
Mitigation Mapping
| Weakness | Better mitigation | Why |
|---|---|---|
| SQL injection | Parameterized queries | Separates data from SQL commands |
| Command injection | Avoid shell execution, use allow lists | Removes interpreter abuse path |
| XSS | Output encoding and sanitization | Prevents untrusted script execution |
| CSRF | Anti-CSRF token and SameSite cookies | Confirms request intent |
| IDOR | Object-level authorization checks | Enforces ownership on every object |
| Path traversal | Canonicalize paths and use allow lists | Prevents escaping intended directories |
| Hardcoded secrets | Secret manager and rotation | Removes secrets from code and images |
| Verbose errors | Generic user errors, detailed server logs | Reduces information disclosure |
| Insecure upload | Type validation, scanning, storage isolation | Limits malicious file execution |
| Race condition | Locking, atomic operations, idempotency | Prevents timing-based logic abuse |
Testing and Review Methods
| Method | Best at finding | When used |
|---|---|---|
| Threat modeling | Design weaknesses and trust boundaries | Before or during design |
| Secure code review | Logic flaws and risky patterns | During development |
| SAST | Source-level issues | CI pipeline or developer workflow |
| DAST | Runtime web behavior | Test environment or staging |
| IAST | Runtime insight with instrumentation | Testing with app context |
| SCA | Vulnerable dependencies and licenses | Build and dependency updates |
| Fuzzing | Crashes and unexpected input handling | Parsers, APIs, native components |
| Secrets scanning | Exposed keys and credentials | Commit, build, and registry checks |
Worked Example: Fix the Root Cause
A developer builds this query by concatenating user input:
SELECT * FROM accounts WHERE owner = '$user' AND status = 'active'
Escaping input may reduce some risk, but parameterized queries are the stronger answer because the database receives the command structure separately from the input value. Least-privilege database accounts also reduce impact if another flaw exists, but they do not replace secure query construction.
Secure SDLC Controls
| SDLC point | Security activity |
|---|---|
| Requirements | Define authentication, logging, privacy, and data protection needs |
| Design | Threat model data flows and trust boundaries |
| Development | Secure coding standards, code review, secrets scanning |
| Build | SAST, SCA, signed artifacts |
| Test | DAST, fuzzing, abuse-case testing |
| Deploy | Hardened configuration and secure secrets injection |
| Operate | Monitoring, vulnerability management, incident feedback |
Common Traps
| Trap | Better exam reasoning |
|---|---|
| "Validate input" as the only XSS control | Output encoding is usually central because context matters |
| WAF as permanent replacement for code fixes | WAF can reduce exposure while code is fixed |
| Hiding buttons to enforce authorization | Server-side authorization must enforce access |
| Logging full secrets for debugging | Logs must not expose passwords, tokens, or sensitive data |
Quick Drill
Choose the most direct mitigation:
- User-controlled search value changes SQL results unexpectedly: parameterized query.
- User changes JSON to include
"role":"admin": allow-list bindable fields and enforce authorization. - Error page reveals stack trace and database path: generic error to user, detailed protected server log.
- API accepts duplicate payment confirmation twice: idempotency key or atomic transaction handling.
Test Your Knowledge
Which control most directly mitigates SQL injection?
A
B
C
D
Test Your Knowledge
A web page displays user comments. Which mitigation is most directly associated with preventing stored XSS?
A
B
C
D
Test Your KnowledgeMulti-Select
Which tools help find vulnerable third-party libraries and exposed credentials in a pipeline? Select two.
Select all that apply
Software composition analysis
Secrets scanning
Jamming detector
Cable toner