Pre-Launch App Security Checks: What to Verify Before Go-Live

TL;DR — Before a new app goes live, it should pass a small set of practical security checks: HTTPS is enforced, admin access is protected, secrets are not stored in code, user input is validated, backups and restore are tested, logs and alerts exist, and the deployment pipeline blocks obvious vulnerabilities. The single most useful takeaway: treat security checks as part of the release pipeline, not a last-minute manual review. Reading time: ~7 min

What it is and where it sits

A pre-launch security check is a release gate (a stop/go checkpoint in the delivery process) that verifies the app, infrastructure, and deployment pipeline are safe enough for real traffic and real data.

This is not one tool. It is a checklist plus a few automated tests that sit between “the app works in staging” and “DNS points customers at production.” In a typical software delivery flow, these checks touch four places:

• the browser or mobile app users interact with
• the web layer (for example nginx, a load balancer, or a platform router)
• the application and database
• the CI/CD pipeline (the automation that builds and deploys releases)

What it replaces: informal approval like “we tested login and it seems fine.” What it adds: repeatable evidence that common launch mistakes were caught.

A typical request and release flow looks like this:

[Developer] ---- 1. push code ----> [CI/CD]
[CI/CD] ---- 2. run tests/scans ----> [Artifact]
[CI/CD] ---- 3. deploy ----> [App]
[User Browser] ---- 4. HTTPS request ----> [Web Layer]
[Web Layer] ---- 5. forward ----> [App]
[App] ---- 6. read/write ----> [Database]
[App] ---- 7. logs/alerts ----> [Monitoring]

The security checks sit mainly at steps 2, 3, 4, 5, and 7:

• Step 2: dependency scan, secret scan, basic static analysis (code inspection)
• Step 3: safe production config, least-privilege credentials (only the minimum access needed)
• Step 4: HTTPS, secure headers, cookie settings
• Step 5: auth checks, rate limits, input validation
• Step 7: audit logs, error tracking, alerting, backup verification

How it actually works

The easiest way to understand this is to walk through one realistic launch example: a customer portal where users sign in, view invoices, and update their profile.

Step-by-step example: customer portal going live

1. The code is pushed to the main branch The CI/CD system starts automatically. Before it builds a release, it runs:

   • unit/integration tests
   • dependency vulnerability scan
   • secret scan to catch API keys accidentally committed to Git
   • build-time checks that production debug mode is off

2. The pipeline builds a release artifact That artifact is the exact package that will be deployed. This matters because you want the thing you tested to be the thing you launch.

3. The deployment uses production secrets from the hosting platform, not from source code In your provider dashboard, this is usually under something like Project/App → Settings → Environment variables. The app receives DATABASE_URL, SESSION_SECRET, and SMTP credentials at runtime.

4. The web layer enforces HTTPS If a user types http://portal.example.com, the web layer redirects them to https://portal.example.com. The TLS certificate (the digital certificate that proves the site identity and enables encryption) must be valid.

5. Security headers are returned with each response The app or web server sends headers like:

   • Strict-Transport-Security to keep browsers on HTTPS
   • X-Content-Type-Options: nosniff to reduce content-type confusion
   • Content-Security-Policy to limit where scripts can load from

6. Login is checked like an attacker would check it The team verifies:

   • passwords are hashed (stored as one-way cryptographic values)
   • session cookies are HttpOnly, Secure, and SameSite=Lax or Strict
   • admin accounts require MFA (multi-factor authentication)
   • rate limiting slows repeated failed logins

7. Authorization is tested, not just authentication Authentication is “who are you?” Authorization is “what are you allowed to access?” A tester signs in as User A and tries to open User B’s invoice URL. The expected result is 403 Forbidden or a safe “not found,” never another customer’s data.

8. Database and storage access are checked The production database should not be publicly reachable from the internet unless there is a very specific reason. In most setups, only the app servers can connect to it.

9. Backups are verified with a restore test A backup that has never been restored is only a hope. The team restores the latest backup into a non-production database and confirms the app can read it.

10. Logs and alerts are enabled before launch Failed logins, 500 errors, deployment failures, and unusual spikes in traffic should create visible alerts. Otherwise, a security issue can be happening silently.

11. A final manual review checks the obvious production mistakes

• default admin accounts removed
• staging/test data removed from production
• debug pages disabled
• robots and indexing settings intentionally chosen
• privacy/legal pages linked if the app collects personal data

That is how the mechanism works in practice: small automated checks in CI/CD, plus a short production-readiness review of the live environment.

When to use it (and when not to)

You should use this for almost every app that will be reachable by real users, especially if it handles accounts, payments, personal data, internal business data, or admin workflows.

Decision guide

You probably do not need a heavy process if...

• the app has no user accounts
• it stores no real customer data
• it is not internet-facing
• it will be short-lived and isolated

Even then, keep three basics: HTTPS, no secrets in the repository, and backups for anything you care about.

Trade-offs

Security checks are valuable, but they are not free.

The practical lesson: the goal is not “maximum security.” The goal is “reasonable, repeatable controls for the app’s real risk level.”

In practice

Below are examples a team can adapt today. The dashboard path should be your first choice; the config examples show what your agency may implement underneath.

Example 1: nginx HTTPS redirect and security headers

If your app runs behind nginx, this is a common baseline. In your hosting provider dashboard, first attach a valid TLS certificate to the domain. Then apply web-server rules like these.

server {
    listen 80;
    server_name app.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name app.example.com;

    ssl_certificate /etc/ssl/certs/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/private/app.example.com/privkey.pem;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Content-Security-Policy "default-src 'self'; img-src 'self' data:; object-src 'none'; frame-ancestors 'self'; base-uri 'self'" always;

    location / {
        proxy_pass http://app_upstream;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

This forces HTTPS and adds baseline browser protections. The gotcha: a strict Content-Security-Policy can break third-party scripts, analytics, or payment widgets until their domains are explicitly allowed.

Example 2: GitHub Actions pipeline with dependency and secret scanning

If your code is in GitHub, go to Repository → Settings → Secrets and variables → Actions to store any needed tokens, then add a workflow like this in .github/workflows/security.yml.

name: security-checks
on:
  pull_request:
  push:
    branches: [main]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v4

      - name: Secret scan
        uses: gitleaks/gitleaks-action@v2

      - name: Set up Node
        uses: actions/setup-node@v4
        with:
          node-version: 22

      - name: Install dependencies
        run: npm ci

      - name: Audit dependencies
        run: npm audit --audit-level=high

      - name: Run tests
        run: npm test

This blocks obvious leaks and known high-severity package issues before deployment. The gotcha: npm audit can fail builds for transitive dependencies (packages you did not install directly), so someone must review whether the issue is reachable in your app before delaying launch.

Example 3: App-level secure session cookie settings

In your app platform dashboard, set environment variables like NODE_ENV=production and a long random SESSION_SECRET. Then configure the app to issue secure cookies.

import session from "express-session";

app.set("trust proxy", 1);
app.use(session({
  name: "sid",
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: {
    httpOnly: true,
    secure: true,
    sameSite: "lax",
    maxAge: 1000 * 60 * 60 * 8
  }
}));

This protects session cookies from JavaScript access and sends them only over HTTPS. The gotcha: if trust proxy is not set correctly behind a load balancer or platform router, secure cookies may not behave as expected.

⚠️ Changing security headers, cookie settings, or HTTPS behavior can log users out or break parts of the app. Apply these changes first in staging, then test login, embedded content, payment flows, and file uploads before production rollout.

Further reading

• OWASP Application Security Verification Standard (ASVS)
• OWASP Top 10
• MDN Web Docs: the "HTTP headers" and "Cookies" sections
• NIST Secure Software Development Framework (SSDF)
• PostgreSQL Documentation: the "Backup and Restore" chapter

This article was written by an AI system and published pending human review. Verify anything you intend to act on.