A practical pre-launch security review for a small team

Right before a launch, security often becomes a sudden worry. Someone asks "wait, are we secure?" and the honest answer nobody wants to say out loud is that no product is ever fully secure, so the question as asked has no good answer. What a small team actually needs is a short, practical check of the things that cause most real problems, done in plain language, so that you launch having fixed the weaknesses that attackers actually use. You can do that, even without a security expert on staff, as long as you know what to check and where your own limits are.

Perfect security is the wrong goal

Start by giving up the idea of perfect. Perfect security does not exist. Any system connected to the internet can, in principle, be attacked, and a determined enough attacker with enough resources can get into almost anything. If your standard for launch is "provably safe against everyone," you will never launch, and you will have spent the time on the wrong thing.

The right goal is different and reachable. Fix the common, serious weaknesses that ordinary attackers actually use, because most attacks are simple and opportunistic: they scan for the easy, well-known mistakes and use the ones people did not fix. And build the ability to notice and respond when something does go wrong, because eventually something will. A good product that is released and monitored is better than a perfect one that exists only as an idea. Aiming for reasonable safety is the mature version of the goal, and it skips no necessary work.

The five basics that find most real problems

For a small team before launch, most of the real risk is in five areas. Go through each one honestly and you will have found most of what would have hurt you.

The first is authentication, which is how your product confirms who a user is. Are passwords stored in a protected form rather than plain text? Are login sessions handled properly, so someone cannot easily steal or guess their way into another account? Is there an obvious way for an attacker to get in that you overlooked? Login is the first thing an attacker tries, and it needs to actually keep them out.

The second is access control, which is what each user is allowed to see and do once they are in. This is one of the most common serious problems on the web, and it is worth explaining in detail. The classic version is that a user can open someone else's data just by changing an ID in the address bar, because the code checked that they were logged in but forgot to check that this particular user was allowed to access this particular item. OWASP, a nonprofit focused on software security, has ranked broken access control first on its list of the most common web application risks. Go through every place that shows or changes sensitive data and confirm it asks the second question as well as the first: "are you logged in" and also "are you allowed to access this."

The third is secrets: your passwords, API keys, and tokens. These must never be stored in your code or in your version history, and never get sent to the browser or printed in logs. A key stored in a public code repository is one of the easiest things for an attacker to find, because they scan for exactly that. And here is the part people get wrong: if a secret was ever committed to your history, even if you deleted it later, treat it as exposed and replace it, because the old version is still there for anyone who looks.

The fourth is dependencies, the outside code your product is built on. Modern software depends on a lot of it, and that code sometimes has published security flaws that everyone, including attackers, can read about. Turn on a tool that automatically scans your dependencies and warns you when one has a known vulnerability, then update the ones that do. This is close to the highest value for the least effort of anything on this list.

The fifth is data handling. Protect sensitive information both while it is sent across the network and where it is stored. Collect only the personal data you actually need, because data you never collected cannot be stolen. And be careful what ends up in your logs, since logs are often less protected than your main database, and a password or a full card number written into a log file is a real exposure. This connects to the broader habit of not letting a rush to launch create hidden risks, which we wrote about in move fast without breaking the product.

Use a known list instead of your imagination

You do not have to invent this checklist from memory, and you should not try, because the things you forget are exactly where the risk is. OWASP publishes a free, widely used list called the OWASP Top Ten that names the most common and serious web application security risks, with plain explanations of each. For a small team it is the right starting point, because it shows you directly the problems attackers exploit most, rather than rare, unusual cases that are interesting to worry about but almost never the cause of a real attack.

Check your product against that list. For each risk, ask a simple question: could this happen to us, and if so, what would we do about it? Most items will match the five basics above. Using an outside, well-maintained list also protects you from the natural habit of checking only the things you already thought of, which are, by definition, not the things you missed.

Know when to bring in a specialist

A generalist pre-launch review handles the basics well, and for many products that is genuinely enough to launch responsibly. But some situations carry enough risk that you should bring in a security specialist, and knowing where that point is counts as doing this properly, with no failure on your part.

Bring in a specialist when the risk is high or the domain is sensitive. If you handle payments, health data, financial data, or large amounts of personal information, the cost of getting it wrong is severe, and a deeper expert review is worth the money. The same is true if you operate in a regulated industry with specific security and privacy requirements, or before a major launch where a breach would be damaging to trust or to the business. The pattern is simple: do the basics yourself because they are learnable and high-value, and pay for a specialist check when the harm from a missed problem is large. Choosing when to spend outside money on expertise you lack is the same judgment we described in in-house vs outsourced engineering.

What has to be right before you launch, and what can wait

Security is an ongoing practice, and you will keep improving it after launch. But a few things cannot wait for "later," because the moment real users and real data are in the product, a weakness in these becomes a real incident rather than a future task.

Before you go live, make sure of three things without exception. No secrets are exposed in your code or history. Users cannot reach each other's data. And login works safely. Everything else on the list should be handled too, but in those three a gap gives attackers a way in on the day you launch, so it cannot wait for the next sprint. After that, keep going: keep scanning dependencies, keep watching your logs for strange activity, and keep fixing weaknesses as you find them. Add the basics during the build rather than at the last minute, and the pre-launch review becomes a confirmation rather than a rush.

The takeaway is calmer than the launch-day panic suggests. Your aim is to fix the common serious weaknesses, protect your users' data, know when the risk is big enough to call in an expert, and be ready to respond when something gets past your checks. Do that, and you can launch calmly instead of with a vague fear that you forgot something important.

Reviewing generated code for security

One addition if a model wrote your implementation, because the risk profile is genuinely different rather than merely larger.

Generated code tends to be conventional, which helps: it uses standard libraries and common patterns rather than inventing its own cryptography. The failures appear in other places. Authorisation checks that exist in the main flow of the code and are missing in a less used one. Input validation that handles the input formats described in the specification and nothing else. Dependencies chosen because they were common in training data rather than because they are currently maintained, which makes dependency and licence scanning non-optional rather than good practice.

The habit worth building is to check the authorisation and validation code specifically, rather than reading the change from start to finish. Reading from start to finish is how you assess whether code is well written. Generated code is usually well written. That was never the question.

Sources

• OWASP, Top Ten most common web application security risks: https://owasp.org/www-project-top-ten/