Tutorial 1: Secure Development and Input Boundaries
Unit 5 · Application and data security
Objectives
Identify untrusted input and output contexts.
Apply validation, encoding, and safe API patterns.
Integrate security into the development lifecycle.
Every input boundary should define expected type, range, length, encoding, and authorization context. Validation is not a single “sanitize” function: reject invalid structure, normalize carefully, and encode output for HTML, SQL, shell, or logging context.
request -> parse -> validate shape and authorization
-> business rule -> parameterized persistence
-> context-aware output encoding
Secure development begins with requirements and threat modeling, continues through code review and automated testing, and ends with dependency and runtime monitoring. Safe APIs make misuse difficult; security comments should explain a trust assumption, not restate syntax.
Exercises
List validation rules for a profile and file-upload endpoint.
Match output encoding to HTML, URL, and JavaScript contexts.
Add a security acceptance criterion to a user story.
Self-check
Why validate structure before business logic?
Why is one sanitizer not universal?
When should security requirements begin?
Self-Check Quiz
1. Who controls server-side validation?
AnswerThe server must validate because all client input is untrusted.
2. What prevents SQL injection?
AnswerParameterized queries or prepared statements, along with authorization and input constraints.
Homework
Threat-model and secure an account-update endpoint.
Write validation and encoding rules.
Define code-review and automated-test evidence.
Sample answerA strong design validates schema and authorization, uses parameterized persistence, encodes output for its context, limits input size, avoids secrets in logs, and tests malicious and boundary inputs before release.