Security Checklist Before Launching a Web App in India

A pre-launch web app security checklist for India covers ten areas: hardened authentication and session management, HTTPS/TLS everywhere, security headers like CSP and HSTS, strict input validation, proper secrets management, dependency and supply-chain scanning, rate limiting on public endpoints, logging and monitoring, tested backups, DPDP Act-aligned data handling, and a final pre-launch VAPT before the domain goes live. Skipping any one of these turns v1 into an easy target on day one, since attackers scan new IP ranges and DNS records within hours of launch. The checklist below walks through each control with what to actually implement, not just what to know.

Why this security checklist matters before day one

Indian founders under launch pressure treat security as a post-launch cleanup task. That's backwards. Automated scanners probe newly registered domains and fresh cloud IP ranges almost immediately after DNS propagates — long before a startup has real users, let alone a security budget. A misconfigured S3 bucket, a debug endpoint left open, or a default admin password found in week one costs far more in incident response and customer trust than the few days it takes to close these gaps before launch.

This isn't a compliance checkbox exercise. It's the minimum bar that separates "we shipped fast" from "we shipped fast and got breached in month one." Each section below is something a founder or small engineering team can implement directly, or verify a vendor has implemented, before the app goes live.

Authentication and session hardening

Authentication is the front door, and most breaches start there. Before launch, confirm:

1. Passwords are hashed with bcrypt, scrypt, or Argon2 — never MD5, SHA1, or plain reversible encryption
2. Multi-factor authentication is available, and enforced for admin and privileged accounts at minimum
3. Session tokens are long, random, generated server-side, and rotated on privilege change (e.g., password reset, role upgrade)
4. Session cookies carry HttpOnly, Secure, and SameSite=Strict or Lax attributes
5. Account lockout or exponential backoff exists on login to blunt credential-stuffing attempts
6. Password reset flows use single-use, time-bound tokens — not predictable links or security questions alone
7. Default or seed admin credentials created during development are rotated or deleted before launch

Enable TLS and set security headers

HTTPS is table stakes, but "we have an SSL certificate" is not the same as "TLS is configured correctly."

1. Force HTTPS everywhere with an HTTP-to-HTTPS redirect; no mixed content, no plaintext fallback
2. Use TLS 1.2 minimum, prefer TLS 1.3, and disable legacy protocols and weak cipher suites
3. Set HSTS (Strict-Transport-Security) with a meaningful max-age so browsers never downgrade to HTTP on repeat visits
4. Set a Content-Security-Policy (CSP) that restricts script, style, and frame sources — this is the single most effective header against XSS and clickjacking chains
5. Add X-Content-Type-Options: nosniff, X-Frame-Options: DENY (or CSP frame-ancestors), and Referrer-Policy: strict-origin-when-cross-origin
6. Verify certificate auto-renewal is configured so the app doesn't silently break when a cert expires post-launch

Validate every input, server-side

Client-side validation is a UX convenience, not a security control — assume every request can arrive crafted by hand.

1. Validate and sanitize all user input on the server, using allowlists (accepted formats/values) over denylists wherever practical
2. Use parameterized queries or an ORM's safe query builder to eliminate SQL injection; never string-concatenate user input into a query
3. Escape output contextually (HTML, JS, URL) to prevent stored and reflected XSS
4. Validate file uploads by type, size, and content — not just file extension — and store uploads outside the web root or in isolated object storage
5. Enforce request size limits and reject malformed JSON/XML early to reduce parser-based attack surface
6. Apply the same validation discipline to API endpoints consumed by a mobile app or partner integration, not just the web UI

Secrets management

Hardcoded secrets in source control are one of the most preventable pre-launch failures.

1. Move all API keys, database credentials, and signing secrets into environment variables or a dedicated secrets manager — never commit them to git
2. Scan your git history (not just the current commit) for previously committed secrets, and rotate any that were ever exposed
3. Use different credentials per environment (dev, staging, production); a leaked staging key should never unlock production data
4. Restrict service-account and API key permissions to the minimum the app actually needs (least privilege), not broad admin scopes for convenience
5. Set up automated secret-scanning in CI so a leaked key is caught before merge, not after launch

Scan dependencies and the supply chain

Modern web apps are mostly other people's code. Your dependency tree is part of your attack surface.

1. Run an automated dependency/vulnerability scan (npm audit, Snyk, GitHub Dependabot, or OWASP Dependency-Check) before every release, not just pre-launch
2. Pin dependency versions and review changelogs before bumping major versions, especially for auth or crypto libraries
3. Remove unused packages, dev-only tools, and debug middleware from the production build
4. Check container base images and any third-party scripts loaded on the frontend (analytics, chat widgets) for known issues — a compromised third-party script is a direct path into your users' sessions

Rate limiting on public endpoints

Without rate limiting, login forms, OTP endpoints, search APIs, and password-reset flows are open invitations to brute force and abuse.

1. Apply rate limits per IP and per account on login, signup, OTP verification, and password reset
2. Add stricter limits or CAPTCHAs on endpoints that trigger costly operations (SMS OTP, email sends, PDF generation)
3. Rate-limit public APIs to prevent scraping and to control infrastructure cost from automated abuse
4. Return generic error responses so rate-limit and lockout behaviour doesn't leak whether an account exists (avoid user enumeration)

Logging, monitoring, and backups

You cannot respond to what you cannot see, and you cannot recover from what you never backed up.

DPDP data-handling basics

India's Digital Personal Data Protection (DPDP) Act 2023 applies to any app processing personal data of Indian users, from day one — there is no "we're too small" exemption for the core safeguard obligations.

1. Collect only the personal data your app actually needs (data minimisation), and avoid over-collecting "just in case" fields at signup
2. Obtain clear, specific consent before collecting personal data, and provide an accessible way for users to withdraw it
3. Apply "reasonable security safeguards" — encryption in transit and at rest, access controls, and breach-detection capability — to any system holding personal data
4. Have a documented process for responding to a personal data breach, since the Act requires timely reporting to affected users and the Data Protection Board
5. Map where personal data is stored and processed (including third-party vendors and analytics tools) so you can actually answer a data-subject access request

Run a pre-launch VAPT

Every control above reduces risk individually, but only an independent Vulnerability Assessment and Penetration Testing (VAPT) exercise validates that they actually work together, under realistic attacker conditions, before real users and real data are on the line.

1. Run automated + manual VAPT covering OWASP Top 10 categories (injection, broken access control, security misconfiguration, and the rest) against the staging or pre-production environment
2. Test authenticated flows specifically — most serious findings live behind login, not on the public marketing pages
3. Re-test after fixes, since a patched finding that reintroduces the same bug in a follow-up commit is common under launch-week pressure
4. For regulated sectors (fintech, healthtech, insurtech), plan for a VAPT delivered with a CERT-In empanelled partner, since some regulators and enterprise customers require that specific credential on the report
5. Treat VAPT as a recurring practice tied to every major release, not a one-time pre-launch gate

Bringing it together

Bachao.AI works with Indian founders shipping v1 web apps who need this checklist executed, not just read. Dhisattva AI Pvt Ltd built the underlying automated scanning approach for teams without a dedicated security engineer who still need to launch defensibly. Whichever controls you implement in-house, treat the final VAPT as non-negotiable — it's the step that turns a checklist into verified evidence.

Explore more launch-readiness and compliance guides on the blog.

External references

1. OWASP Top 10 — owasp.org/www-project-top-ten
2. OWASP Secure Headers Project — owasp.org/www-project-secure-headers
3. CERT-In advisories — cert-in.org.in
4. MeitY — Digital Personal Data Protection Act 2023 — meity.gov.in