How to Check Web Application Security Before Launch
A practical pre-launch security checklist for web apps: authorization, secrets, data, dependencies, logs, and recovery.
In brief
- • Authorization must be checked on every sensitive action.
- • Secrets, logs, and backups are security concerns too—not just source code.
- • Before launch, define an incident and recovery plan.
ContentsShow sections
Web application security is not a single switch or a promise that “everything is protected.” Before launch, use a focused checklist to catch expensive mistakes: exposed data, excessive permissions, leaked keys, and missing recovery.
This article does not replace a full audit or penetration test. For critical data, involve a qualified security professional.
1. Check authentication and authorization
- a user cannot access another user's object by changing an ID in the URL;
- each role sees only permitted sections and actions;
- the server checks permissions instead of only hiding UI buttons;
- sessions, logout, and account recovery behave predictably;
- administrative and internal routes are not open to ordinary users.
OWASP recommends checking authorization on every request, using least privilege, and denying access by default. A useful starting point is the OWASP Authorization Cheat Sheet.
2. Check secrets and data
- keys are not in the repository, client-side JavaScript, or public logs;
- test data does not contain real personal information;
- backups are protected and have a retention policy;
- public files do not expose private documents;
- forms and APIs validate type, size, and allowed values.
3. Check dependencies and infrastructure
List the libraries, services, and environments. Clarify who owns security updates, where logs live, and how access to the server and database is restricted. Prioritize dependencies that handle authentication, payments, file uploads, and user data.
4. Prepare monitoring and recovery
| Question | Minimum answer |
|---|---|
| How will you notice an issue? | Important errors and actions are logged |
| Who responds? | An owner and contact method are named |
| How do you roll back? | A tested procedure is documented |
| How do you recover data? | A backup has been restored in a test |
For a broader control set, use the OWASP Application Security Verification Standard. It is a verification standard, not a certificate or a replacement for product-specific risk assessment.
Before launch
- Test in a separate environment with safe data.
- Remove temporary accounts and keys.
- Check ordinary-user and administrator permissions.
- Document rollback steps and responsible contacts.
- Review logs and critical flows again after release.
If the project is complex or handles sensitive data, request a security review and development work with a defined scope.
Security review levels for freelancers
Agree on the exact review before starting. A basic pre-launch check can cover roles, forms, file uploads, secrets, logs, and backup recovery. It is not the same as a penetration test, threat model, or formal compliance audit.
| Level | Result | Best for |
|---|---|---|
| Basic checklist | Obvious issues and recommendations | Small site or MVP |
| Critical-flow review | Deep check of billing, roles, or data | Product before first launch |
| Specialized audit | Formal report against a selected standard | Sensitive or regulated systems |
If you do not run specialized testing regularly, do not call a basic review a “security guarantee.” Say exactly which flows were checked and which risks were found. This is more professional and avoids false confidence.
Questions for the product owner
- which data is sensitive;
- which actions could cause financial loss;
- which roles exist and who assigns them;
- which external services may be unavailable;
- who receives an incident alert;
- what recovery time is acceptable.
How to estimate the work
Price security by scope and hours, not by a promise to “check everything.” Split preparation, test flows, fixes, and retesting. The client needs both findings and priority: what must be fixed before launch, what can be planned, and what needs a specialist.
Do not include unlimited consulting, full infrastructure remediation, or legal security responsibility in a basic quote. Write these boundaries before work starts.
After launch
A pre-release check does not replace monitoring. Review logs, failed logins, API errors, and unusual uploads during the first hours. Clarify how dependencies and backups are maintained. Without this, even a good pre-launch review becomes outdated.
Minimum evidence of review
Record the date, environment, and flows that were actually checked. For every risk, note impact, priority, owner, and retest. Never store real passwords, tokens, or personal data in the report.
If a client asks for a “security guarantee,” explain which area and depth you can review. Clear boundaries are part of secure work, not an avoidance of responsibility.
Describe the result in plain language
Instead of “a security review was completed,” write: “an ordinary user could not access another record, invalid input was rejected, a temporary key was removed, and a backup was restored in test.” A concrete result is understandable and repeatable by another developer.
When a problem is found, keep evidence from before and after the fix. Security then becomes part of delivery, not a decorative phrase in a proposal.