Topics / Build Securely / Application and Code Security
Application and Code Security
Secure application design, implementation, review, and testing.
Intended audience: Beginners, practitioners, and security engineers relevant to this discipline.
8 results
A Practical Secure Code Review Checklist
A defensive, risk-focused checklist for reviewing software changes before approval.
Securing API Authentication and Authorization
How token-based API authentication and authorization actually fail in practice, and a repeatable procedure for reviewing object- and function-level checks before they do.
Secrets Detection: What Automated Scanners Miss
Why regex- and entropy-based secrets scanners routinely miss real credentials — and the compensating controls that close the gap instead of asking pattern matching to do the impossible.
Dependency Confusion and Package-Name Trust
How package managers resolving names across mixed internal and public registries can be tricked into installing an attacker-controlled package instead of your own — and the namespace-reservation and single-source resolution controls that close the gap.
Why Input Validation Is Not a Complete Security Control
Input validation confirms a request is well-formed — it does not confirm the request is safe. What validation actually catches, what it structurally cannot, and the authorization, output-encoding, and parameterized-query layers that have to sit alongside it.
SAST vs DAST vs Software Composition Analysis
What Static Application Security Testing, Dynamic Application Security Testing, and Software Composition Analysis each actually catch, what each structurally cannot catch given how it works, and how to combine them into a defensible layered testing approach instead of assuming one tool is sufficient.
Preventing Path Traversal Through Boundary Validation
Path traversal happens when an application resolves a user-influenced path against a filesystem boundary it assumed but never enforced. Why blocking literal '../' substrings is a well-known incomplete mitigation, and how to canonicalize a resolved path and verify it against an explicit allow-listed root instead.
Designing Security Tests for Failure Conditions
Conventional test suites cover the happy path plus a few expected errors, which systematically misses where security decisions actually break: a dependency timeout, a malformed upstream response, a partial multi-step failure, a race around a check-then-act decision. How to deliberately inject each of those conditions and assert the system fails closed, not just that it doesn't crash.
Related categories