Security is not a layer you add to finished software. It is a lens you apply from the first line of code — and it starts by asking what an adversary would do with what you are building.
Most developers think about security the way most people think about insurance: something you deal with after the fact, when something has gone wrong or when someone external demands it. A security audit is scheduled. A penetration test is commissioned. Findings are triaged. Patches are shipped. This model is broken, and the reason it is broken is simple: it treats security as a property of finished software rather than as a property of the thinking that produces software.
The Attacker's Advantage
Attackers have a structural advantage over defenders. They only need to find one path through your defenses. You need to close all of them. They can choose their timing, their vector, and their target. You must defend everything, all the time, against threats you have not fully anticipated. The only way to meaningfully narrow this gap is to adopt the attacker's mindset during design and development — not after deployment.
“It takes 20 years to build a reputation and a few minutes of a cyber incident to ruin it.”
— Stéphane Nappo
Threat Modeling Before You Write a Line
Threat modeling is the practice of systematically asking 'what could go wrong?' before you build anything. The STRIDE framework — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege — gives you a structured vocabulary for this. For every component you design, work through each category. Who could impersonate an authenticated user? What data could be tampered with in transit? What actions could a user take that should be undeniable?
- Spoofing: Can an attacker pretend to be a legitimate user or system component?
- Tampering: Can data be modified in transit, at rest, or in processing without detection?
- Repudiation: Can users deny having taken an action? Are your audit logs trustworthy?
- Information Disclosure: What sensitive data could leak through errors, logs, or side channels?
- Denial of Service: What inputs or behaviors could degrade or destroy availability?
- Elevation of Privilege: Can a low-privilege actor gain capabilities they should not have?
Input as the Permanent Enemy
The single most productive security mindset shift for a developer is to treat all input as hostile until proven otherwise. This sounds paranoid because it is paranoid — and paranoia is the correct default when you do not control what enters your system. SQL injection, XSS, command injection, path traversal, XML bombs, deserialization gadgets — almost all of these are variants of the same fundamental mistake: trusting that input will conform to your expectations.
Validate, Sanitize, Escape — In That Order
Validation is checking that input conforms to expected type, length, format, and range. Sanitization is removing or neutralizing dangerous content. Escaping is ensuring that when data is rendered in a different context — HTML, SQL, shell — it cannot be interpreted as code. These are distinct operations and all three are often necessary. The mistake is skipping validation because you will sanitize, or skipping escaping because you validated. Each layer addresses different failure modes.
Secure-by-Default Design
The most resilient systems are those where the insecure path requires more effort than the secure path. If your framework makes it easy to parameterize queries and hard to concatenate SQL strings, developers will naturally end up writing safer code. If your internal APIs require authentication by default and must be explicitly marked public, the default posture is closed. Designing for secure-by-default means thinking about the choices developers on your team will make under time pressure — and making the right choice the path of least resistance.
Principle of Least Privilege in Practice
Every process, service account, database user, and API token should have exactly the permissions required for its function — nothing more. This is easy to state and routinely violated because broad permissions are convenient. The cost of this convenience is that a single compromised component can become a foothold for lateral movement across your entire system. Audit your permission grants with the same skepticism you would apply to an unfamiliar pull request.
The Code Review as Security Review
Every code review is an opportunity to do a mini threat model. When you review a pull request, ask: where does untrusted data enter this code path? Where does authentication or authorization happen — and where is it conspicuously absent? What happens if this external call fails or returns unexpected data? Are secrets hardcoded? Are dependencies pinned? Does the error handling reveal internal structure that an attacker could use? You do not need to find every vulnerability — you need to make finding vulnerabilities expensive.
Log What Matters, Protect What You Log
Security incidents are investigated through logs. Logs that do not exist, are incomplete, or are themselves compromised are useless when you need them most. Log authentication events, authorization failures, data access patterns, and anomalous behavior. Do not log passwords, tokens, or PII — your logs may be stored, aggregated, and accessed by people and systems that should not see that data. Logs are a security control. Treat them with the same care as your most sensitive application data.
“The hacker mindset doesn't actually see what happens at your website — they see what happens to the data that passes through it.”
— Bruce Schneier
Writing code like a hacker does not mean writing code that hacks. It means writing code with the constant awareness that someone will attempt to misuse it, and designing from the beginning to make that attempt as difficult, detectable, and costly as possible. It is not a skill you add later. It is a perspective you develop now.