1. Secure coding: keep untrusted data from becoming executable instructions
Many application vulnerabilities occur at an interpreter boundary: user-controlled data reaches SQL, HTML/DOM, an operating-system shell, a filesystem path resolver, a file handler, or an HTTP redirect mechanism in a form that changes program behavior.
2. Interactive secure coding simulator
[LAB] No real command, query, file, script, redirect, or upload will execute.
3. Vulnerable vs. secure code
4. Mini SAST review lab
This is a teaching approximation of static analysis. It does not compile or parse the language. It identifies the dangerous coding pattern represented by the selected example and explains what a real reviewer or SAST rule should investigate.
5. Countermeasure matrix
Defense-in-depth controls
Why the primary defense matters
6. Guided student laboratories
Lab 1 — SQL injection: code versus data
Select SQL Injection and the tautology input. Run the vulnerable implementation, then the secure implementation in all four languages. Explain what parameter binding changes at the database boundary.
Lab 2 — XSS: encoding depends on output context
Use the script-bearing markup preset. Compare vulnerable and secure output. Explain why HTML-text encoding is not automatically the correct defense for JavaScript, CSS, URL, or HTML-attribute contexts.
Lab 3 — Command injection: remove the shell
Use the shell-separator probe. Compare construction of one command string with a fixed executable plus separated arguments. Identify the role of input allowlisting and least privilege as additional controls.
Lab 4 — Path traversal: normalize before authorization
Run the traversal input. Explain why merely checking for the literal sequence ../ is weaker than canonicalizing/resolving the path and enforcing that the final path remains under an approved root.
Lab 5 — File upload: filename is untrusted input too
Run the path-bearing filename and compare storage patterns. Identify at least five checks or architectural controls that should be considered for a production upload feature.
Lab 6 — Open redirect: constrain navigation
Use the external destination and scheme-relative destination. Explain how open redirects can support phishing even when the vulnerable application itself is not serving the attacker’s final content.
Lab 7 — Secure code review exercise
For each vulnerability family, write a one-sentence code review rule that a reviewer could use during a pull request. Then map each rule to a SAST, DAST, IAST, code-review, or architectural control.
Lab 8 — DevSecOps pipeline placement
Design a pipeline showing where linting, SAST, SCA, secret scanning, unit security tests, DAST, container scanning and release gates should occur. Identify which controls could detect or prevent each issue represented in this simulator.
7. Ten-question knowledge check
8. References and further reading
| Reference | Use in this lab | Link |
|---|---|---|
| OWASP SQL Injection Prevention Cheat Sheet | Prepared statements / parameterized queries and defense in depth. | OWASP |
| OWASP Cross Site Scripting Prevention Cheat Sheet | Context-sensitive output handling and safe framework practices. | OWASP |
| OWASP OS Command Injection Defense Cheat Sheet | Avoiding direct OS command invocation, structured arguments, validation and least privilege. | OWASP |
| OWASP Path Traversal | Directory traversal concepts and defensive considerations. | OWASP |
| OWASP File Upload Cheat Sheet | Upload validation, naming, storage, permissions and defense in depth. | OWASP |
| OWASP Unvalidated Redirects and Forwards Cheat Sheet | Safe redirects and destination validation. | OWASP |
| OWASP ASVS 5.0 | Application-security verification requirements for secure development and testing. | OWASP |
| NIST SP 800-218 — SSDF | Secure software-development practices integrated into the SDLC. | NIST |