Secure by Design from Day Zero

Here’s a pattern I see constantly: a team ships a feature, it works great, everyone’s happy. Then three weeks later someone finds an authorization gap, or a log that captures nothing useful, or an input that was never validated because it came from “a trusted internal service.” The feature goes back for rework. The sprint gets disrupted. Everyone is annoyed.

The frustrating part is that none of it was inevitable. Those problems were created at design time, not discovered at review time. Security debt isn’t like regular technical debt where you make a conscious tradeoff. Most of the time it accumulates because nobody explicitly thought about it early enough. And by the time you do think about it, the code is already shaped in ways that make fixing it painful.

I’ve been burned by this enough times that it changed how I start features entirely. This post is about the habits that came out of that.

Define trust boundaries before the first line of code

The single most useful thing I do at the start of any feature is draw the trust boundaries before writing anything. Not a formal threat model, not a lengthy document. Just: where does untrusted input enter this system, and what path does it take to produce an output or mutation?

This sounds obvious but it’s easy to skip when you’re excited to build something. You open your editor, you start with the happy path, and you make implicit assumptions about where data comes from. Those assumptions are where vulnerabilities live.

Concretely: I identify every surface that accepts external input. API endpoints, webhook receivers, file uploads, query parameters, headers, anything that arrives from outside the service. I write those down. Then I ask what the worst-case interpretation of each input is. Not what it’s supposed to contain. What it could contain.

// the question isn't "what does this field normally hold"
// the question is "what happens if it holds something adversarial"
void process_user_input(const std::string& input) {
    // before anything else: what are the valid values?
    // what happens if input is empty? 10MB? binary data? SQL?
    if (input.empty() || input.size() > MAX_INPUT_LENGTH) {
        throw ValidationError("input out of acceptable range");
    }
    // now you can proceed with some confidence
}

That mental shift, from “what is this supposed to be” to “what could this be,” changes the code you write at every layer.

The other thing trust boundary mapping does is make authorization questions explicit early. Who is allowed to trigger this action? On whose behalf? Under what conditions? If you can’t answer those questions before you write the endpoint, you will answer them implicitly in the code, and implicit authorization logic is almost always wrong in at least one edge case.

Map abuse cases during planning, not testing

Most planning sessions produce user stories: “as a user, I want to do X so that Y.” That framing is useful for building features. It’s useless for building secure features, because legitimate users aren’t the problem.

I’ve gotten into the habit of adding abuse cases to planning alongside the user stories. For every “as a user, I want to upload a profile picture,” I want a corresponding “as an attacker, I want to upload a file that gets executed on the server.” For every “as a user, I want to view my account details,” I want “as an attacker, I want to view someone else’s account details by manipulating the ID in the request.”

This isn’t pessimism. It’s just completing the picture. A feature that handles the legitimate case but not the adversarial case isn’t finished.

Abuse cases also force better API design. When you’re thinking about how a request could be abused, you naturally end up with smaller, more explicit interfaces. Functions that take exactly the parameters they need, not a generic object you’ll destructure inside. Endpoints that do one thing. The adversarial lens and the good-design lens point in the same direction more often than not.

Instrument logs for investigations, not just uptime

This one took me the longest to internalize, because logging feels like an operational concern rather than a security concern. It’s both.

When something goes wrong, and something always eventually goes wrong, the quality of your logs determines whether you can understand what happened or whether you’re guessing. “Error 500 at 14:32” is not useful. “User ID 8471 attempted to access resource owned by user ID 2209 at 14:32 from IP 203.0.113.42, returned 403” is useful. The second one tells you something happened that you should investigate. The first one tells you a request failed.

The difference is thinking about logs as an investigation tool rather than a health check. When I add logging to a feature, I ask: if something bad happened here, what would I need to know to reconstruct the event? The answer usually includes actor identity, the action attempted, the resource involved, and the outcome. Not always all of those, but that’s the starting point.

// not this
logger.info("user updated");

// this
logger.info("user_update", {
    actor_id: current_user.id,
    target_user_id: params.user_id,
    fields_modified: modified_fields,
    ip: request.remote_ip,
    timestamp: now()
});

The second version takes maybe thirty extra seconds to write and it’s the difference between being able to respond to an incident and filing a “we don’t know what happened” report.

One thing I want to be clear about: audit logs are not the same as application logs. Application logs help you debug. Audit logs help you answer “who did what, when, and to what.” They serve different purposes, they often have different retention requirements, and mixing them together makes both worse. Separating them is worth doing from the start.

The practices that have actually stuck

After enough projects, the things that consistently prevent security rework have simplified into a short list.

Every external input gets explicit validation before anything else happens with it. Not “we sanitize it later,” not “it comes from a trusted source.” Explicit validation at the entry point, every time. The question is never whether to validate, only what the valid range actually is.

Access is denied by default. This means the code path for “is this allowed” should start from “no” and move to “yes” when conditions are met, not start from “yes” and add exceptions. Default-deny is a mindset as much as a pattern. It means when you add a new operation, you explicitly decide who can perform it rather than inheriting whatever the previous thing allowed.

Secrets have no business in source code, ever. Not in comments, not in test files, not in config files that get committed. Environment variables, secret managers, whatever your stack provides. And a rotation plan: if a secret is compromised, how fast can you replace it? If the answer is “we’d have to redeploy everything and it would take hours,” that’s a risk worth addressing before it’s urgent.

Audit trails capture actor, action, and context. Not just that something happened, but who caused it, what they did, and enough context to understand why it matters. This is the log design from the previous section applied consistently across the whole system.

Why this makes shipping faster, not slower

The pushback I sometimes hear on secure-by-design practices is that they slow you down. In my experience the opposite is true, but the payoff is delayed enough that it’s easy to miss the connection.

When you define trust boundaries early, you write less code overall because you don’t build things that turn out to be wrong. When you map abuse cases during planning, you don’t discover them during a security review after the PR is already written. When your logs are instrumented for investigations from the start, you debug production incidents faster because you have the information you need.

The security work doesn’t disappear. It moves earlier, where it’s cheaper. A question asked at planning costs five minutes. The same question asked after the feature ships costs a sprint.

That’s the actual argument for secure by design: not that it’s the right thing to do (though it is), but that it’s the faster thing to do once you account for the full lifecycle of a feature. Security stops feeling like friction and starts feeling like just how you build things. And once it feels that way, you stop noticing the extra five minutes at the start, because you also stop having the bad weeks at the end.