The problem
I started from a problem I recognized from ordinary backend work: an API can return the right response to a normal user and still be unsafe when its identifiers, body fields or outbound destinations are manipulated. I wanted to test the cases that a happy-path feature test overlooks.
Engineering question: Can each security boundary reject malicious inputs while preserving the corresponding legitimate business operation?
Security controls and regression strategy
| Threat | Security decision | How it was challenged |
|---|---|---|
| BOLA / IDOR | Constrain order access using identity-derived ownership, not just a numeric order ID. | Use another user's known order ID; expect a non-disclosing 404. |
| Mass assignment | Allowlist mutable profile fields through a narrow update contract. | Attempt to submit privileged fields beyond the approved DTO. |
| SQL injection | EF Core LINQ and PostgreSQL/Npgsql parameterization instead of string-built SQL. | Attack-shaped search values and PostgreSQL parameterization regressions. |
| SSRF | Remove arbitrary outbound destination selection; restrict remote host and redirects. | Invalid identifiers, unintended hosts, redirect responses. |
| Browser security | Safe Angular binding, CSRF controls, CORS and security headers. | HTML event-handler payloads, cross-origin and cookie-based request attempts. |
| Uploads & abuse | Validate uploads/paths and apply per-operation limiting. | Traversal-shaped paths, malformed files and abuse-probe responses. |
Case note: a valid login was not valid ownership
“The endpoint knew who was calling. It still needed to prove which order that user could read.”
In the original lab exercise, an order lookup using only the resource ID allowed a user to reach an object owned by somebody else. The fix added ownership to the EF Core query predicate using the authenticated principal.
Positive and negative tests cover authorized access, cross-user denial, anonymous denial and list/search isolation. My takeaway: the security question is not only “who is this?” but also “does this exact row belong to the caller?”
Evidence and review
On the verified integrated master revision, the project completed its .NET CI with 53 passing backend tests and zero build warnings. The M12 security review also recorded successful automated security checks across static analysis, dependency analysis, secret scanning, CycloneDX SBOM and real OWASP ZAP DAST in its separately reviewed CI context.
DAST found zero High and zero Medium alerts in the reviewed scan scope, not zero vulnerabilities throughout every possible endpoint. Negative workflow fault paths were explicitly simulated, not actual outages.
What this demonstrates
- Translating OWASP-style threat categories into concrete requests and assertions.
- Writing both negative and positive tests so security does not break legitimate users.
- Considering frontend, API, persistence, outbound requests and build tooling as separate boundaries.
- Reporting evidence honestly: scan coverage is narrower than complete application security.
Limitations
I present this as a private educational lab, not a live production service or an independently performed penetration test. Not every business-logic path was exhaustively exercised by DAST. Raw self-hosted-runner logs are not presented publicly, and future changes would require updated evidence.
← Back to all case studies