Secure Coding
Write software that resists attack by default — from authentication and access control to input validation, output encoding, cryptography and safe logging. Learn the secure-coding practices behind the SANS SWAT checklist and OWASP, and make them stick with spaced repetition.
- practice cards
- 51
- practice cards
- per day
- ~10 min
- per day
- level
- Beginner → Intermediate
- level
- modules
- 3
- modules
What is secure coding?
Secure coding is the practice of writing software that resists attack by default — validating every input, encoding every output, protecting data in transit and at rest, and failing safely when something goes wrong. It is the developer-side counterpart to a penetration test: instead of finding holes after the fact, you avoid opening them. This track distils the SANS SWAT secure-development checklist and its matching CWE weaknesses into questions you can actually retain.
The deck is organised the way real application security is. Authentication & Access Control covers password policy, brute-force lockout, session management, least privilege and complete mediation. Input, Output & Data Protection covers allowlist validation, parameterised queries, contextual output encoding, CSRF and security headers, TLS and password storage. Error Handling, Logging & Operations covers safe error messages, what to log and what to never log, and secure build and deploy practices.
Every card ties back to a concrete weakness — SQL injection (CWE-89), session fixation (CWE-384), sensitive data in logs (CWE-532) — and links to the relevant OWASP Cheat Sheet. Spaced repetition turns a checklist you skim once into instincts you apply in every pull request and code review.
3 modules, seed to bloom
Each module is a set of practice cards — 51 in total. Answer, review, and watch your knowledge grow from seed to full bloom.
Authentication & Access Control
Authentication, session management, and access-control fundamentals
17 cardsInput, Output & Data Protection
Input validation, output encoding, and protecting data in transit and at rest
19 cardsError Handling, Logging & Operations
Error handling, security logging, and secure build and operations practices
15 cardsSample questions
A taste of the real cards. Pick an answer, then reveal the explanation.
Which flags should be set on session cookies?
- AHttpOnly, Secure, and SameSite — blocking scripts, forcing HTTPS, and mitigating CSRF
- BDomain, Path, and Max-Age — scoping the cookie's reach and controlling its lifetime
- CPriority, Partitioned, and Size — tuning how the browser stores the cookie on disk
- DPublic, Private, and no-store — the cache-control directives applied to the cookie
How should an application prevent SQL injection?
- AUse parameterized queries with bind variables — never building SQL by string concatenation
- BEscape quotes and special characters in the input — before concatenating it into the SQL
- CStrip SQL keywords such as SELECT and DROP — out of every value that the user submits
- DRun the database account with read-only rights — so injected queries cannot modify data
How should an application store user passwords?
- AA strong, iterative, salted hash such as bcrypt or PBKDF2 — with a per-user random salt
- BA single pass of a fast hash like SHA-256 — applied directly to the raw user password
- CSymmetric encryption with a server-side key — so the passwords can be decrypted if needed
- DA hash using one shared application-wide salt — appended to every user's password value
How should an application handle an exception it did not anticipate?
- ACatch it in a handler that returns controlled, generic output — never leaving it unhandled
- BLet it propagate to the framework's default handler — which shows a full stack-trace page
- CWrite the raw exception into the response body — so the user can report the details back
- DRetry the failing operation over and over until it succeeds — hiding the error from view
Learn it once, keep it for good
Answer a question
Each card is one practical concept with multiple options. Pick what you think is right.
Get the full answer
See the correct option plus a clear explanation, and a link to deeper docs when one is available.
Review at the right time
A spaced-repetition engine (SM-2 or FSRS) resurfaces each card just before you would forget it.
Why secure coding is worth your time
Ship fewer vulnerabilities
Catch injection, XSS, weak sessions and leaky errors while you write the code — not after a pentest report lands.
Grounded in real standards
Built from the SANS SWAT checklist and CWE, with every card linking to the matching OWASP Cheat Sheet for deeper reading.
Review with confidence
Know why each answer is right and why the plausible alternatives are wrong — the exact judgement a security code review needs.
Interview and certification ready
Authentication, access control, injection defence and crypto storage are staples of appsec interviews and secure-development exams.
Common questions
Who is this track for? +
Developers, DevSecOps engineers and code reviewers who want to write and approve safer code. It assumes general web-development experience but starts each topic from fundamentals.
Which standards does it follow? +
The questions are drawn from the SANS SEC540 / SWAT secure-development checklist and mapped to CWE weaknesses. Each card links to the corresponding OWASP Cheat Sheet (or MDN / NIST) for deeper reading.
Is it tied to one language or framework? +
No. The principles — input validation, output encoding, session management, TLS, password storage and safe logging — apply across languages and stacks, so the deck stays language-agnostic.
Is it free? +
Yes, completely free. No registration or credit card is required, and all your progress is stored locally in your browser.
Ready to write more secure code?
Plant your first seed today. Ten minutes a day builds secure-coding instincts you'll reach for in every code review.