Application security checklist before launch

A useful application security checklist is short enough that people actually use it, and specific enough to catch real problems. Most security trouble in new apps comes from ordinary gaps rather than clever attacks. Think of a password form that lets someone guess forever, an admin page anyone can open if they know the address, a secret key left in the code, or a backup nobody has ever tried to restore.

We wrote this for product owners, founders and engineering leads who are close to launching a web or mobile app and want to know what to check. It's about defence: what to put in place, and how to confirm it works. Use it to ask your team better questions and to spot gaps while they're still easy to close.

What does an application security checklist cover?

Secure software development means thinking about security at every stage of the work instead of bolting it on the week before release. Something that takes an hour to fix at the design stage can take weeks once the code is live. That's why we split the checklist into four stages.

The four stages of the checklist

1. DesignData, roles and risks.
2. BuildSign in, access, input, secrets.
3. Final gateBefore launchTesting, backups, monitoring.
4. After launchUpdates, reviews, incident plan.

What should you decide at the design stage?

Before a line of code is written, get a few things down on paper. What data will the app hold? Who can do what? And what would hurt most if it went wrong? People call this threat modelling. It's really just an organised conversation about what could go wrong and how you'd stop it.

• List the data you collect. Mark which items are personal (names, emails, addresses) and which are sensitive (payment details, health records, identity documents).
• Collect only what you need. This is the simplest privacy protection there is, because data you never store can't leak.
• Define the roles. Customer, support agent, manager and administrator are typical. Write down what each one may see and change.
• Decide how long you keep data and how it gets deleted when that time is up.
• Check which rules apply to you, such as the UK GDPR or EU GDPR (the data protection laws for people in the UK and Europe), plus any sector rules for payments or health data.

How should sign in and passwords work?

Your sign in page is the front door, so it's where automated password guessing hits hardest. A handful of simple measures stop almost all of it.

• Offer two factor sign in, where people confirm with a code from an authenticator app, or use a passkey, as well as their password. Make it compulsory for staff and administrators.
• Limit sign in attempts. After several failed tries in a short time, slow down or pause that account or address, so nobody can guess passwords at speed.
• Store passwords with a slow hashing method such as Argon2 or bcrypt. A hash is a one way scramble, so not even your own team can read a password.
• Allow long passwords and check them against lists of passwords already leaked in past breaches, instead of forcing awkward symbol rules.
• Keep error messages vague. "Email or password is incorrect" doesn't tell anyone which accounts exist.
• Make sessions expire, and end every session when someone changes their password or signs out.

How do you get access control right?

Sign in (authentication) confirms who someone is. Access control decides what they're allowed to do once they're in. OWASP ranks broken access control as the top risk for web apps, and it's easy to miss, because everything looks fine to ordinary users.

• Use role based access. Permissions belong to roles and people are given roles, so access stays consistent and is easy to review.
• Check permission on the server for every request. Hiding a button in the app doesn't protect anything on its own. The server has to refuse the action too.
• Check who owns each record, so a customer who changes a number in the address bar can't see someone else's order.
• Start everyone with the least access. New roles begin with nothing and get only what they need.
• Protect admin areas with two factor sign in and, where you can, limit them to your company network.

What is the OWASP Top 10 and why does it matter?

OWASP (the Open Worldwide Application Security Project) is a nonprofit community that publishes free security guidance. Its best known document, the OWASP Top 10, lists the most common and serious risks in web applications. It makes a sensible starting point for any team, and most security reviews refer to it. Here are the main risks on the current 2025 list:

When it comes to input, assume nothing from outside can be trusted. That covers form fields, file uploads, data sent by mobile apps and replies from other systems. Check it against what you expect, use parameterised queries (so the database treats input as data and never as part of the command), and encode output so text appears on the page as text instead of running as code. If you're building for phones, read the OWASP Mobile Top 10 as well. It's the matching list for iOS and Android apps.

Where should secrets and keys live?

Secrets are the passwords, API keys and certificates your app uses to talk to databases and other services. An API (application programming interface) key is simply a password that one system uses to call another.

• Never put secrets in the code or inside a mobile app, where anyone who downloads it can dig them out.
• Keep them in a secrets manager such as AWS Secrets Manager, Azure Key Vault or HashiCorp Vault.
• Use different secrets in each environment, so a test key can never touch live data.
• Scan your code history for secrets saved by mistake, and change any you find.
• Change keys on a regular schedule, and straight away when someone with access leaves.

How do you manage third party packages?

Most of a modern app is code written by other people: open source libraries, frameworks and software development kits. That saves a lot of time. It also means every package you add is a way in that someone else built.

• Keep a list of every package and its version. A software bill of materials is the formal name for this list.
• Scan for known flaws automatically with tools such as GitHub Dependabot, Snyk or npm audit, and act on what they find.
• Choose packages carefully. Go for ones that are widely used and still looked after.
• Remove what you don't use, because unused code still needs updating.
• Review third party scripts like chat widgets and analytics tags. They run with the same access as your own code.

What does encryption at rest and in transit mean?

Encryption in transit protects data as it travels between the user, your app and your servers. Encryption at rest protects it where it's stored: on disks, in databases and in backups.

• Use HTTPS everywhere, with TLS 1.2 or later (TLS is the standard that secures web traffic), and that includes traffic between your own internal services.
• Switch on encryption for databases, file storage and backups. On most cloud platforms it's a single setting.
• Keep encryption keys in a key management service, and give access only to the people and systems that need it.
• Add extra protection to the most sensitive fields, such as identity numbers, so even most of your own staff can't read them.

What should you check before launch?

Use the last few weeks before launch to prove that everything above actually works. It's too late to start adding new protections now. Treat this list as your final gate.

• Logging is in place. You record sign ins, failed attempts, permission changes and admin actions, and you never write passwords or payment details into the logs.
• Alerts reach a real person, for example when failed sign ins pile up or errors suddenly rise, and someone is named to respond.
• Backups run automatically and are stored away from the live system.
• You've tested a restore. Until you've restored a backup, you don't know it works.
• Test and debug features are switched off on the live system, and error pages show no technical detail.
• Automated security scans run in CI/CD (an automated pipeline that tests and releases every change), so new problems get caught before release.
• A penetration test is done, and every serious finding is either fixed or has an agreed plan.

What is penetration testing before launch?

In a penetration test, qualified security testers try to find weak spots in your app. They work with your written permission, within an agreed scope and time window. You see what a real attacker might find while there's still time to fix it.

• Agree the scope in writing: which apps, environments and accounts are included, and which aren't.
• Test a copy of the live system if you can, filled with realistic data rather than real customer records.
• Leave time to fix what they find. Book the test two to four weeks before launch, not two days.
• Retest the fixes, so you know each problem is properly closed.

What happens after launch?

Launch day isn't the end of security work. New flaws turn up in popular packages every week, and your own app keeps changing.

• Apply security updates quickly, and set a target time for urgent ones.
• Review who has access regularly, say every quarter, and remove accounts people no longer need.
• Check your privacy notice still matches what the app really collects.
• Repeat penetration testing after big changes and at least once a year.
• Give people a way to report problems, such as a security contact address on your site.

Do you need an incident plan?

Yes. An incident plan is a short written guide to what you do if something goes wrong, like a data leak, a hacked account or the service going down. If you write it calmly beforehand, it saves hours of confusion on a very bad day.

• Name who's in charge and who decides what customers are told.
• List the first steps: contain the problem, keep the evidence and bring the service back safely.
• Know what you have to report. Under GDPR, some personal data breaches must be reported to the regulator within 72 hours.
• Practise once a year with a short exercise, and update the plan afterwards.

Write your incident plan while nothing is on fire.

How V6 Cube helps with application security

Our application security services work these checks into every stage, starting with threat modelling at design and running through to penetration testing before launch and security reviews afterwards. We set up encryption, secrets management and monitoring as part of our cloud and infrastructure work, and we keep apps patched through software maintenance and support. Read how our software development process runs, or look at the lending platform we built with 63% faster approvals, where sensitive financial data needed protecting from day one. If you're still choosing who to work with, our guide on how to choose a software development company lists the questions worth asking. The stakes are highest where the data is most sensitive, as in finance and banking software and healthcare software.