What Penetration Testing Taught Me About Writing Better Code

For eight months I split my time between offensive security work at RNP, doing adversary emulation and vulnerability assessments, and full stack development at Bridge Laboratory, shipping features in React, TypeScript, Kotlin and Spring Boot. Those two jobs do not usually sit in the same head. They changed how I write code.

Pentesting trains a specific habit: before touching a system, ask where an attacker gets leverage. Not "does this feature work" but "what happens if this input is malformed, this token is replayed, this endpoint is hit without auth". That question does not go away when you switch from breaking things to building them.

The clearest carryover is input validation. After enough time finding injection points and broken auth checks in other people's systems, I stopped treating validation as a formality on my own pull requests. Every endpoint gets the same question a pentest engagement asks: what is the worst input this parameter could receive, and does the code survive it.

Dependency hygiene is the second habit. Vulnerability assessments spend real time on outdated packages with known CVEs, because that is often the actual way in, not some clever zero day. Running npm audit or equivalent before a release stopped being a checkbox and became muscle memory.

Authentication and session handling get more scrutiny too. Working with Kali Linux and adversary emulation tooling makes token replay, session fixation and privilege escalation concrete failure modes instead of abstract OWASP list items. Code review questions change from "does login work" to "what happens if this token is reused after logout".

The tension is real, though. Development optimizes for shipping; security optimizes for reducing attack surface. A pentest mindset can slow a team down if every decision gets treated as an incident. The habit that actually transfers well is not paranoia, it is asking the attacker question early, at design time, when it costs nothing to fix, instead of after the feature ships.

Building this portfolio and its blog system was a small test case for this. Data lives in Supabase behind row level security, the blog CMS validates and sanitizes every field before it reaches the database, and image uploads go through a scoped storage bucket instead of arbitrary file writes. None of that is exotic. It is the same checklist a pentest engagement runs, applied while the code is still being written instead of after someone tries to break it.

Full stack engineering and offensive security keep circling back to the same question: what did I assume that is not actually guaranteed. Answering that earlier is cheaper than answering it during an incident.