Pro Logica

    Replit App Security Check

    Replit makes it easy to go from an idea to a published app, often with Replit Agent writing most of the code. The question most builders search next is simple: is my Replit app secure? The answer usually depends on one distinction that's easy to miss. A secret stored safely in Replit can still end up in your users' browsers.

    The Pro Logica AI App Security Check is a free, passive scan of your published Replit app. Paste the URL and you get a score out of 100 with findings ranked by severity in about a minute. Run a free Replit app security check.

    Replit Secrets vs. secrets in your frontend

    Replit's Secrets tool encrypts your API keys and tokens and hands them to your app as environment variables. That's the right place for them, and it keeps them out of your code when you share or remix the project. Replit's docs note that secrets work for every deployment type except Static Deployments, and published apps can use separate Production app secrets (Publishing → Adjust settings).

    Secrets only stay secret if server-side code reads them. Here's how they leak anyway:

    • Build-time inlining. If your frontend uses Vite, any variable named VITE_… is copied into the JavaScript bundle at build time. Name a secret VITE_OPENAI_KEY and it ships to every visitor, even though it lives in the Secrets tool.
    • Calling the API from the browser. If a React component calls a paid API directly with your key, the key has to be in the browser. Move that call into an Express, Flask or FastAPI route, and have the browser call your route.
    • Hard-coded fallbacks. Code like process.env.KEY || "sk-live-…" puts the real value in the source anyway.

    We read your homepage and up to eight of your own JS files and look for live secret patterns: Stripe live secret keys, AWS keys, OpenAI and Anthropic keys, GitHub and Slack tokens, SendGrid keys, private key blocks, and Supabase service_role keys. Anything we find is masked, and we never store the full value. If one shows up, rotate it at the provider first. Then move it to a server-only secret. The full walk-through is in Exposed API key in frontend.

    Headers on Replit

    Replit gives you HTTPS, but your app sends whatever headers your code (or your deployment config) sets. Most starter templates set none.

    • Autoscale or Reserved VM (most Agent-built apps): set headers in the app. For Express, the helmet middleware adds a sensible set of security headers in one line, app.use(helmet()), which you then tune. For Flask or FastAPI, add a small middleware that sets Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options: nosniff, Referrer-Policy and frame-ancestors.
    • Static Deployments: add [[deployment.responseHeaders]] entries (each with path, name and value) to the .replit file in the project root, then republish.

    How common is this gap? In our passive check of 18 public showcase apps built with Lovable or Bolt, 18 of 18 had no Content-Security-Policy. We didn't sample Replit apps, but the cause is the same: nothing sets the header unless you ask. More in Missing security headers.

    Files that shouldn't be public

    A common Replit pattern is a Node server with express.static(".") or a Python server that serves the project folder. That can publish your .env file, your .git folder, and your production source maps along with your HTML. When you confirm you own the app, we check /.env and /.git/HEAD once each, and we test whether .js.map files are reachable. Serve only your build folder (for example dist/ or public/), never the project root. See Source maps exposed in production.

    Indexability: can Google find you?

    Your score also covers basic indexability, because an app nobody can find doesn't get sign-ups. We flag a noindex tag or header, a missing <title>, a missing meta description, and a missing sitemap. In our 18-app sample, 15 of 18 had no sitemap we could find. If you use a custom domain, make sure it's the one Google sees. Put your sitemap at /sitemap.xml, add a Sitemap: line to robots.txt, and submit it in Google Search Console.

    A Replit security checklist

    1. All keys live in Secrets, and no secret is named VITE_ or NEXT_PUBLIC_.
    2. Paid API calls happen in server routes, never in the browser.
    3. The server only serves the build folder.
    4. Security headers are set by middleware or in .replit.
    5. Production uses its own secrets, separate from testing.
    6. You rescan after every big Agent change.

    Related

    FAQ

    Are Replit Secrets safe?

    Replit encrypts them at rest and in transit and exposes them to your app as environment variables. They're safe as long as only server-side code reads them. A secret that a frontend build step copies into the bundle is public.

    My Replit project is public. Can people see my secrets?

    According to Replit's visibility rules, visitors to a cover page can't see secret names or values, and people who remix your project get the names but not the values. Your deployed app's JavaScript is a separate thing. Anything in it is visible to everyone, which is what our scan checks.

    Does Replit add security headers?

    Replit handles HTTPS. Headers like CSP and HSTS come from your app or your static deployment config, so add them yourself and confirm with our scan or curl -I.

    Will the scan affect my Replit usage or uptime?

    It sends at most about 40 GET and HEAD requests, paced out. It doesn't log in or write anything, and it respects robots.txt for page fetches.

    What's in the full report?

    Each finding with masked evidence, a plain-English fix, and a copy-paste prompt written for Replit Agent.

    Find out what your Replit app shows the world. Run the free Replit security check.

    By Pro Logica