Foundations · Module 3
Implementation and build
Write secure, maintainable code with proper input validation, output encoding, session management, error handling, and supply chain security.
Previously
Architecture and design
Document and communicate architectural decisions using C4 models, Architecture Decision Records, API contracts, and security by design principles.
This module
Implementation and build
Write secure, maintainable code with proper input validation, output encoding, session management, error handling, and supply chain security.
Next
Verification and testing
Ensure quality and security through comprehensive testing strategies, OWASP ASVS integration, accessibility testing with WCAG 2.2, and performance testing.
Progress
Mark this module complete when you can explain it without rereading every paragraph.
Why this matters
This is about secure defaults and clean boundaries.
What you will be able to do
- 1 Explain implementation and build in your own words and apply it to a realistic scenario.
- 2 Implementation is safer when guardrails prevent common mistakes and failures are visible.
- 3 Check the assumption "Inputs are untrusted" and explain what changes if it is false.
- 4 Check the assumption "Errors are safe" and explain what changes if it is false.
Before you begin
- No previous technical background required
- Read the section explanation before using tools
Common ways people get this wrong
- Silent failure. Silent failure breaks trust and increases incident cost.
- Leaky errors. Leaky errors expose internals and help attackers.
Write secure, maintainable code with proper input validation, output encoding, session management, error handling, and supply chain security.
This is about secure defaults and clean boundaries. We focus on the common failures that appear when code meets real users.
Mental model
Implementation with guardrails
Implementation is safer when guardrails prevent common mistakes and failures are visible.
-
1
Input
-
2
Validate
-
3
Logic
-
4
Data access
-
5
Logs
Assumptions to keep in mind
- Inputs are untrusted. Assume external input can be malicious or broken. Validation is part of correctness.
- Errors are safe. Errors should be visible to operators and safe for users. Do not leak internals.
Failure modes to notice
- Silent failure. Silent failure breaks trust and increases incident cost.
- Leaky errors. Leaky errors expose internals and help attackers.
Check yourself
Quick check. Implementation and build
0 of 5 opened
What is input validation for
To reject malformed or malicious input at the boundary, so downstream code does not have to guess what it received.
Scenario. A user enters '<script>' into a form. What protects the page when you render it later
Output encoding and safe templating, plus storing and handling data as untrusted by default.
Why does session expiry matter
It reduces the window for account takeover and limits long lived access when devices or tokens are leaked.
What is a CVE in plain terms
A publicly tracked vulnerability. In practice it is a known weakness you may need to patch or mitigate.
What is least privilege for secrets
Only the systems and people who need a secret can access it, and access is scoped, logged, and rotated.
Artefact and reflection
Artefact
A short module note with one key definition and one practical example
Reflection
Where in your work would explain implementation and build in your own words and apply it to a realistic scenario. change a decision, and what evidence would make you trust that change?
Optional practice
Secure coding, session management, error handling, and supply chain security