Most websites and apps that get broken into aren’t beaten by genius hackers. They get caught by the basics: an admin page anyone can open, an API key sitting in the browser code, a checkout that trusts whatever price the browser sends. None of that shows up when you click around your own site. It shows up after launch, when someone goes looking for it.
That’s why we run a pre-launch security checklist on every site and app we build: 27 checks covering logins, keys and secrets, data, payments, server settings and code. Below is the full list in plain English, what each check protects you from, and how to use it, whether you build with a developer, an agency, or an AI coding assistant like Claude.
- Most launch-day security problems are simple mistakes, not advanced attacks, and you can catch them with a checklist.
- The 27 checks fall into six groups: logins and access, keys and secrets, data and forms, payments, server settings, and code and dependencies.
- Run the checks before launch. Fixing a leaked key or an open admin route after go-live costs far more than catching it first.
- The last step matters most: test that each protection actually works, and get a written report of what was found and fixed.
Watch: the 27 checks in 60 seconds
We turned the whole checklist into a one-minute video. It’s the same list we work through on client builds, shown as the prompts you’d give an AI coding assistant before launch.
Why every site and app needs a pre-launch security check
Building software has never been faster. A small business can go from idea to a working booking app in a week, and AI coding tools have made “just ship it” the default. The catch is that speed tends to skip the boring parts, and the boring parts are where security lives.
The industry’s own data backs this up. The OWASP Top 10, the most widely used list of web application risks, puts broken access control at the top: people reaching pages and data they were never meant to see. Close behind are injection, weak authentication, security misconfiguration and outdated components. Almost every item on our checklist maps to one of them.
US government guidance points the same way. CISA’s Secure by Design program asks software makers to build protection in from the start instead of bolting it on later. A pre-launch checklist is the practical, small-business version of that idea.
The 27 pre-launch security checks, in plain English
The numbers match the order in the video. We’ve grouped them here by what they protect.
1. Logins and access (7 checks)
- #1 Set up proper authentication. Sign-ins are checked by the server, not just hidden behind a button in the browser.
- #5 Hash passwords. Passwords are stored as one-way hashes, so a leaked database doesn’t hand anyone your customers’ passwords.
- #9 Lock down admin routes. The server checks every admin request. Hiding the link isn’t the same as locking the door.
- #12 Add rate limiting. The login page and forms limit how many tries a visitor gets, which stops password-guessing bots.
- #15 Secure session cookies. Login cookies are set to HttpOnly, Secure and SameSite, and they expire on their own.
- #16 Add CSRF protection. Important actions, like changing an email or a payment method, need a token that a malicious site can’t fake.
- #17 Make password-reset links expire. Reset links work once and for a short window, not forever.
2. Keys and secrets (4 checks)
- #2 Hide API keys. Secret keys for payments, email and other services stay on the server and never ship in browser code.
- #11 Check environment variables. Anything marked “public” really is safe to be public. Secrets are kept server-side only.
- #24 Scan the Git history for leaked secrets. A key deleted from today’s code can still sit in an old commit. Tools like GitHub secret scanning help find them.
- #25 Revoke and replace compromised keys. If a key ever leaked, deleting it from the code isn’t enough. Cancel it and issue a new one.
3. Data and forms (5 checks)
- #3 Secure the database. The database isn’t reachable from the internet, and the app connects with the fewest permissions it needs.
- #6 Validate forms on the server. Browser checks are for convenience. The server re-checks every value, like a booking for “-3 seats.”
- #7 Protect against XSS. Anything a visitor types, such as a comment or a name, is shown as text and can never run as code on someone else’s screen.
- #10 Use parameterized queries. User input is passed to the database as data, never pasted into the query, which closes the door on SQL injection.
- #18 Restrict file upload types and sizes. Uploads are checked for type, size and real content, so “photo.jpg” can’t turn out to be a script.
4. Payments (1 check)
- #19 Verify prices and payments. The server sets the price and confirms the payment with the provider. A shopper editing the page to pay $1.00 for a $149 plan gets nowhere.
5. Server settings (6 checks)
- #4 Enforce HTTPS. Every page loads over an encrypted connection, and plain HTTP redirects to it.
- #8 Log and monitor suspicious activity. Repeated failed logins and odd requests are logged, and someone gets an alert.
- #13 Restrict CORS settings. Only your own approved sites can call your API from a browser, not the whole internet.
- #14 Add security headers. Headers such as Content-Security-Policy and Strict-Transport-Security tell browsers what’s allowed to load and how.
- #20 Disable debug mode in production. Visitors see a friendly error page, not a stack trace with file paths and database details.
- #23 Check for exposed files. Backups,
.envfiles, database dumps and.gitfolders can’t be downloaded from the website.
6. Code and dependencies (4 checks)
- #21 Update vulnerable dependencies. Third-party packages with known security holes are patched before launch.
- #22 Remove unused packages. Less code means fewer places for a problem to hide.
- #26 Run a thorough security review. One pass over the whole system: sign-in, secrets, data, network, payments, files, inputs and packages.
- #27 Test the protections and write a report. Every fix is tested to prove it works, and the results go into a short report of findings and fixes.
| Group | Checks | What it stops |
|---|---|---|
| Logins and access | 7 | Account takeovers, open admin pages, password guessing |
| Keys and secrets | 4 | Stolen API keys and surprise bills on your accounts |
| Data and forms | 5 | Database leaks, injected code, malicious uploads |
| Payments | 1 | Tampered prices and fake orders |
| Server settings | 6 | Snooping, leaked error details, downloadable backups |
| Code and dependencies | 4 | Known holes in third-party code, untested fixes |
Using this checklist with an AI coding assistant
The video is written as a request to Claude because more and more apps are being built with AI help. AI assistants are good at this work when you ask for it directly. They’re less reliable when you assume they did it on their own. A few tips:
- Go one check at a time. “Review my sign-in and session handling” gets a better answer than “make it secure.”
- Ask for findings and fixes, not just fixes. You want to know what was wrong, not only that something changed.
- Make it prove the fix. Ask it to test each protection, for example by trying the admin page while logged out, and show you the result.
- Keep a human in the loop. An AI review is a strong first pass. For anything that takes payments or stores personal data, have someone experienced check the result.
Want your AI assistant to run all 27 checks for you? Our free Pre-Launch Security Checklist repo has every check with a test you can run, a drop-in Claude Code skill, a copy-paste prompt for any other AI assistant, and a PASS / FAIL report template.
Get the checklist on GitHub →How NTL of NYC runs this on every build
Security is part of our build process, not an add-on. Every site and app our web design and development team ships goes through the same toolkit before it goes live:
- Checklist. We work through all 27 checks against the real build, not a template.
- Fix and retest. Anything we catch gets fixed and tested again, so “fixed” means proven, not assumed.
- Report. You get a plain-English summary of what we checked, what we found, and what we changed.
- After launch. With our hosting and maintenance plans, updates, monitoring and alerts keep running after go-live.
If you’re building with AI tools in-house, our automations and AI and consulting teams can review what you’ve built and give you the same report before you launch.
The bottom line
You don’t need a security team to avoid the most common launch-day mistakes. You need a checklist, the discipline to run it before go-live, and proof that each fix works. Start with the six groups above. If you’d like a second pair of eyes, talk to us before you launch.