.png&w=3840&q=75)
A client asks, partway through a project, whether security has been "included." It's a reasonable question to ask and a slightly strange one to need to ask security isn't a feature a team remembers to add if there's time left in the budget. It's a set of defaults that should already be there, the same way a building has locks on the doors before anyone asks whether it does.
Authentication that doesn't rely on users being careful
Password-only login, with no additional protection, puts the entire weight of account security on users remembering to pick something strong and never reusing it anywhere else which is, reliably, not what happens at scale. Multi-factor authentication and secure session handling aren't advanced features reserved for a security-conscious client who asks for them specifically. They're defaults, because the realistic alternative is accounts that get compromised through no fault of the system's design, just through ordinary human password habits.
Treating every input as something that could be wrong on purpose
Most security incidents in ordinary web applications don't come from some exotic attack. They come from a form field, a URL parameter, or an API request that was trusted to contain what it was expected to contain, and didn't. Validating and sanitising input consistently, everywhere data enters a system, closes the overwhelming majority of common vulnerabilities not because it's a clever technique, but because it removes the assumption that attackers will only ever send well-behaved data.
Secrets that live somewhere other than the code
An API key or database credential committed into a codebase, even briefly, even in a private repository, is a mistake that tends to outlive the commit that fixed it, history doesn't forget as easily as a team hopes. Centralised secrets management, where credentials are injected at runtime rather than written into source code, removes an entire category of exposure that's otherwise just waiting for the day someone makes the repository public by accident, or a laptop gets into the wrong hands.
Encryption as a default, not a response to a request
Data encrypted in transit and at rest should be the baseline for anything handling real user information, not a tier reserved for clients who specifically ask for "the secure version." The cost of building this in from the start is small. The cost of retrofitting it after a breach, alongside the damage to trust that a breach causes, is considerably larger and far less within anyone's control to manage gracefully.
Dependencies that get watched, not just installed
Modern applications lean heavily on third-party packages, and a meaningful share of real-world vulnerabilities trace back to an outdated dependency with a known, published issue that nobody was tracking. Automated dependency scanning as part of the regular development process catches this before it becomes an incident, rather than after a researcher or an attacker finds it first.
Access that narrows as roles narrow
A common quiet failure mode: permissions granted generously early on, when the team is small and everyone touches everything, that never get revisited as the team and the system grow. Someone who needed broad access for a one-off task eighteen months ago often still has it, long after the reason for it disappeared. Scoping access deliberately, and reviewing it periodically rather than only when someone leaves, closes a gap that doesn't require an attacker at all, just an account that was never supposed to be this powerful for this long.
What this means when evaluating a partner
None of the above should need to be requested as an add-on during a scoping conversation. The useful question to ask a prospective development partner isn't "do you do security" — everyone says yes to that. It's more specific: how do you handle authentication by default, where do secrets live, and what happens when a dependency gets flagged with a known vulnerability. A team that has clear, specific answers to those questions, without needing to check internally first, is one that's already building this in rather than bolting it on when asked.
