Secure Coding and Application Mitigations
Key Takeaways
- Secure coding prevents vulnerability classes before deployment through input handling, output encoding, authentication, and authorization.
- Parameterized queries, allow-list validation, output encoding, and safe error handling map directly to OWASP-style web risks tested on SY0-701.
- SAST, DAST, IAST, SCA, fuzzing, and secrets scanning each find a different class of weakness.
- Apply mitigations as close to the root cause as possible; WAF and RASP are useful but usually compensating controls.
- A secure SDLC adds threat modeling, security requirements, testing gates, and dependency governance at each phase.
Fix the Class, Not Just the Symptom
Secure-coding questions on SY0-701 ask for the control that prevents a vulnerability class, not one that merely detects attacks after release. The strongest answer is normally the one closest to the root cause; perimeter tools like a WAF (web application firewall) buy time but do not fix the code.
Mitigation Mapping
| Weakness | Best mitigation | Why it works |
|---|---|---|
| SQL injection | Parameterized queries (prepared statements) | Separates data from SQL command structure |
| Command injection | Avoid shell calls; use allow lists | Removes interpreter abuse path |
| Cross-site scripting (XSS) | Context-aware output encoding and sanitization | Prevents untrusted script execution |
| Cross-site request forgery (CSRF) | Anti-CSRF token plus SameSite cookies | Confirms request intent |
| Insecure direct object reference (IDOR) | Object-level authorization checks | Enforces ownership on every object |
| Path traversal | Canonicalize paths and use allow lists | Blocks escaping the intended directory |
| Hardcoded secrets | Secret manager and rotation | Removes secrets from code and images |
| Verbose errors | Generic user errors, detailed server logs | Reduces information disclosure |
| Insecure file upload | Type validation, scanning, storage isolation | Limits malicious file execution |
| Race condition (TOCTOU) | Locking, atomic operations, idempotency | Prevents timing-based logic abuse |
The most common trap pairs XSS with "input validation only." Input validation helps, but output encoding is central because the same data is dangerous in HTML, attribute, JavaScript, and URL contexts differently, and encoding is applied where the data is rendered.
Two defensive habits underpin most of the table. Allow-list (whitelist) validation accepts only known-good input and rejects everything else; it is far stronger than deny-list (blacklist) filtering, which tries to enumerate bad input and always misses a new bypass. And the principle of least privilege applied to service and database accounts limits the damage when a flaw slips through, which is why least-privilege accounts appear as a secondary control beside the primary code fix.
Testing and Review Methods
Each tool finds a different class. Match the tool to what the stem describes.
| Method | Best at finding | When used |
|---|---|---|
| Threat modeling | Design weaknesses and trust-boundary gaps | Before/during design |
| Secure code review | Logic flaws and risky patterns | During development |
| SAST (static analysis) | Source-level issues without running code | CI pipeline or developer IDE |
| DAST (dynamic analysis) | Runtime web behavior, no source needed | Test or staging environment |
| IAST (interactive) | Runtime issues with code-level context | Instrumented test runs |
| SCA | Vulnerable dependencies and license risk | Build and dependency updates |
| Fuzzing | Crashes and bad-input handling | Parsers, APIs, native components |
| Secrets scanning | Exposed keys and credentials | Commit, build, registry checks |
Know the SAST-versus-DAST distinction cold: SAST reads source code early and pinpoints the vulnerable line but produces false positives; DAST attacks the running app like an outsider, so it confirms exploitability but cannot point to the exact code.
Worked Example: Fix the Root Cause
A developer builds a query by concatenating user input:
SELECT * FROM accounts WHERE owner = '$user' AND status = 'active'
Escaping input reduces some risk, but parameterized queries are the stronger answer because the database receives the command structure separately from the value, so injected SQL is treated as literal data. Least-privilege database accounts reduce blast radius if another flaw exists, but they do not replace secure query construction. A WAF can block obvious payloads temporarily; it is a compensating control, not the fix.
Secure SDLC Controls
Security belongs at every phase of the software development lifecycle (SDLC), not bolted on at the end.
| SDLC phase | Security activity |
|---|---|
| Requirements | Define authentication, logging, privacy, 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 config, secure secret injection |
| Operate | Monitoring, vulnerability management, incident feedback |
Two deployment-side controls round out the picture. Code signing proves an artifact came from a trusted publisher and was not altered after build, so consumers can reject tampered binaries. Input sanitization at trust boundaries plus secure default configurations (fail closed, no debug endpoints in production) prevent a hardened codebase from being undone by a careless release. The exam treats the SDLC as a chain: a flawless code review means little if the build pulls an unsigned dependency or the deploy step injects a secret into a logged environment variable.
Common Traps
| Trap | Better exam reasoning |
|---|---|
| "Validate input" as the only XSS control | Output encoding is central because context matters |
| WAF as a permanent code-fix replacement | WAF reduces exposure while code is fixed |
| Hiding buttons to enforce authorization | Server-side authorization must enforce access |
| Logging full secrets for debugging | Logs must never expose passwords or tokens |
Quick Drill
Choose the most direct mitigation:
- A user-controlled search value changes SQL results unexpectedly: parameterized query.
- A user edits JSON to add
"role":"admin": allow-list bindable fields and enforce server-side authorization (mass-assignment). - An error page reveals a stack trace and database path: generic user error, detailed protected server log.
- An API accepts a duplicate payment confirmation twice: idempotency key or atomic transaction handling.
- A comment field stores
<script>that runs for later viewers: context-aware output encoding (stored XSS).
Which control most directly mitigates SQL injection?
A web page displays user comments. Which mitigation is most directly associated with preventing stored XSS?
Which tools help find vulnerable third-party libraries and exposed credentials in a pipeline? Select two.
Select all that apply