Secure Your AI-Built Website or App Before Launch

What you'll finish with: a working project that has passed a practical pre-launch security baseline, with no known launch-blocking issues left unresolved.

IMPORTANT

This guide helps you catch and fix common pre-launch security problems. It is not a penetration test and does not mean your application is "100% secure."

Create a Safe Checkpoint

Keep Your Current Work Saved on a Git Branch or Checkpoint If You Don't Use Git, Make a Backup Copy of the Project

Do not use real customer data while testing the steps in this guide.

Run the Pre-Launch Security Audit

Open your project with Claude Code, another coding agent, or the AI development tool you normally use. Use this prompt first.

Audit My Project Without Changing It

Perform a pre-launch security audit of this project. IMPORTANT: - Do not modify any files yet. - Do not commit, push, deploy, or change production services. - Never print complete API keys, passwords, tokens, cookies, connection strings, private URLs, or other secret values in your response. Refer only to the variable name and file/location. - Base every finding on evidence from this project. Do not invent vulnerabilities just because a technology could theoretically have them. First identify the actual architecture and features used by this project: - frontend/framework - backend/API routes/serverless or edge functions - database - authentication provider - file storage/uploads - external APIs - AI APIs or other usage-based services - payments/webhooks - hosting/deployment configuration - package manager and major dependencies Then audit the project for the most important pre-launch risks: 1. Secrets and private credentials exposed in frontend code, public environment variables, repository files, logs, or configuration. 2. Sensitive third-party API calls that should run on the server but currently expose a private credential to the browser. 3. Authentication weaknesses. 4. Missing or incorrect authorization: users accessing other users' records, admin actions protected only in the UI, insecure object IDs, or backend/database access without ownership checks. 5. Database access rules, including RLS/security rules when the platform supports them. 6. Public or expensive endpoints that can be abused repeatedly, including AI, email, SMS, uploads, generation, search, or other paid operations. 7. Missing server-side input validation, unsafe rendering, injection risks, dangerous URL fetching, or unsafe file uploads. 8. Payment or webhook security problems if payments exist. 9. Production security misconfiguration, unsafe CORS/cookie settings, excessive error details, sensitive logging, debug/development configuration, or unnecessary public endpoints. 10. Known vulnerable or clearly unsafe dependencies that matter to this project. Special rules: - Do NOT classify a Supabase publishable key or legacy anon key as a secret merely because it is visible in the browser. Instead verify that RLS, grants, and policies correctly protect the data. - Supabase secret keys and legacy service_role keys are private and must never be exposed to the browser. - In Vite projects, assume VITE_* variables are visible in the client bundle and verify that none contains a private secret. - Authentication alone is not proof of authorization. - Hiding an admin page or button in the frontend is not an authorization control. - Billing alerts are not a replacement for application-level abuse controls or rate limiting. Return a concise report with exactly these sections: PROJECT MAP A short summary of the architecture and security-sensitive features you found. BLOCK LAUNCH Only confirmed issues serious enough that I should not launch before fixing them. Include severity, evidence/location, risk, and recommended fix. IMPORTANT Confirmed improvements that should be handled before or shortly after launch but are not immediate launch blockers. LOOKS GOOD Important controls you checked and found correctly implemented. NOT APPLICABLE Security areas from this audit that this project does not use. NEXT ACTION Tell me which category I should fix first. Do not make any changes yet.

IMPORTANT

Read the BLOCK LAUNCH section carefully. The next steps fix those problems one category at a time — do not ask the AI to "fix the whole report" in one operation.

Fix Secret Exposure and Client/Server Boundaries

A frontend application is public. Anything shipped to the browser should be treated as visible to users. That does not mean every key visible in the browser is a secret — some services intentionally provide public client keys. Use this prompt to fix the dangerous cases without breaking legitimate client-side integrations.

Protect Secrets and Private API Calls

Now fix the secrets and private API boundary issues found in the security audit. Work only on this category. Do not start fixing unrelated security findings yet. Requirements: 1. Search for private credentials that may be exposed through: - frontend source code - public environment variables - VITE_*, NEXT_PUBLIC_*, PUBLIC_*, or similar client-exposed variables - hardcoded strings - committed .env/config files - logs or debug output - API responses - repository configuration 2. Classify each credential correctly before changing anything: - public/publishable credential designed for client use - private/server-only credential - uncertain and requiring provider documentation 3. Do not treat a Supabase publishable key or legacy anon key as a private secret simply because it is in frontend code. Verify its data access is protected through appropriate RLS, grants, and policies. Supabase secret keys and legacy service_role keys must remain server-side only. 4. In a Vite project, treat all VITE_* values as browser-visible. A private credential must not be stored there. 5. For every private third-party API key currently required by browser code, move the sensitive operation behind the appropriate existing backend layer: - server API route - server action - serverless function - edge function - or the equivalent supported by this project's architecture. 6. The frontend should call our backend. The backend should call the private external service. 7. Validate requests on the backend before using the private service. 8. Ensure private environment files and generated secret files are ignored by source control where appropriate. 9. Never print or copy actual secret values into your response. 10. Do not automatically delete public-by-design keys or break legitimate browser integrations. 11. Preserve existing functionality and make the smallest safe changes. After the changes: - run the relevant build/tests - search the client-facing code again for remaining private credentials - list every file changed - list any manual action I still need to perform Do not commit, push, or deploy.

Rotate Any Secret That Was Already Exposed

Moving an exposed secret out of the frontend prevents future exposure, but it does not make the old credential private again. If the audit found a private key that was already:

Committed to a Repository Included in Frontend Code Deployed in a Client Bundle Otherwise Publicly Exposed

Open that provider's dashboard and revoke or rotate the exposed credential. Then add the replacement only to the appropriate server-side environment. If no private secret was exposed, you can skip this action.

IMPORTANT

Do not paste the replacement key into an AI chat. Configure it directly through your local environment or hosting/provider secret settings.

Fix Authentication and Authorization

If your project has no user accounts, private dashboard, database records, admin area, or protected content, the AI may mark parts of this step as not applicable. Signing in proves who a user is. It does not automatically prove which records or actions that user should be allowed to access. Use this prompt.

Lock Down Users, Records, and Admin Access

Now audit and fix authentication, authorization, and user-data isolation in this project. Work only on this category and use the architecture already discovered. My goal is not only to make login work. I need the server/database to enforce what each user is actually allowed to read, create, update, delete, or administer. Check and fix: 1. Protected operations that rely only on frontend route guards, hidden buttons, hidden admin pages, or client-side role checks. 2. Backend/API routes that accept user IDs, record IDs, organization IDs, account IDs, or other object identifiers without verifying that the authenticated user is allowed to access that specific object. 3. Horizontal access problems where User A could read, edit, or delete User B's records. 4. Vertical privilege problems where a normal user could trigger admin-only actions. 5. Database queries that return more data than the current user should receive. 6. Create/update operations where the client can assign ownership, role, account, price, permissions, or other sensitive fields that should be decided server-side. 7. Authentication/session configuration that is clearly unsafe for this stack. 8. Cookie-based authentication: verify appropriate secure cookie settings and CSRF protection for state-changing operations where the framework does not already provide it safely. Platform-specific requirements: - If this project uses Supabase, inspect RLS, grants, and policies for tables/views/functions reachable by anon or authenticated users. Verify user-owned data is scoped correctly. Do not use a secret/service_role key as a shortcut for normal user requests that should respect RLS. - If it uses Firebase, inspect the relevant Security Rules rather than relying only on application code. - If it uses another backend/database, enforce equivalent authorization on the trusted server/database side. Security rules: - Deny access by default where appropriate. - Validate authorization for the specific requested resource, not just whether a user is logged in. - Do not rely on IDs being hidden or difficult to guess. - Do not change intentionally public data into private data without evidence that it should be private. Make the smallest safe changes and preserve expected product behavior. Then: - run relevant tests/build checks - add or update authorization tests where practical - list the access-control rules now being enforced - tell me exactly what I should verify manually with two test accounts Do not commit, push, or deploy.

Perform the Two-User Test — User A

Do not rely only on the AI report for this step. Create two test accounts and test cross-access yourself.

Sign In as User A

Create a Private Record, Project, Order, Document, Profile Item, or Other User-Owned Data

Perform the Two-User Test — User B

Sign In as User B, Separately

Try to Open User A's Resource Using Its URL or ID if Available

Try the Relevant Read, Edit, and Delete Actions

Try Any Admin-Only URL or Action You Can Identify

Test a Protected Resource While Logged Out

Check the Pass Condition

IMPORTANT

User B must not gain access simply by changing or reusing an ID or URL, and a normal user must not be able to execute privileged operations. If User B can access User A's private data, treat this as a launch blocker. Do not continue toward production assuming the frontend will hide the problem.

Build a Full Web App + Backend with Supabase

Use this only if your project still needs a proper authentication/database foundation. You do not need to rebuild a working backend just to follow this security guide.

RESOURCE

https://profitstudio.app/video/build-full-webapp-supabase

Protect Expensive and Public Endpoints

A private API key can be perfectly hidden and still cost you money if anyone can repeatedly trigger the backend endpoint that uses it. This matters especially for AI, email, SMS, file processing, generation, search, and other usage-based services.

Add Abuse and Resource Protection

Now audit and protect this project's public, expensive, or resource-intensive backend operations from abuse. Do not apply one arbitrary global rate limit to the entire application. First identify endpoints or actions that can consume meaningful money or resources, including when present: - AI or LLM requests - image/audio/video generation - email or SMS sending - OTP/password recovery - file uploads or processing - search or scraping - external paid APIs - expensive database/report operations - imports/exports - anonymous form submissions - other operations that could be automated repeatedly For each relevant operation, determine the appropriate protection based on its real use. Implement where appropriate: 1. Authentication before expensive operations that should not be anonymous. 2. Endpoint-specific rate limiting or throttling. 3. Prefer user/account-based limits for authenticated usage, with additional IP-based protection where useful. 4. Reasonable request/payload/input-size limits. 5. Upload size limits where uploads exist. 6. Limits on pagination, batch size, or number of operations per request. 7. Server-side timeouts or execution limits where supported. 8. For AI features: - server-side input length limits - sensible output/token limits - allowed models/features controlled server-side - per-user or per-account usage protection when appropriate - no direct exposure of private provider keys 9. Prevent repeated triggering of sensitive flows such as email, SMS, OTP, password recovery, or invitation endpoints. 10. Return safe 429/validation responses without exposing internal details. Use the framework/platform's established capabilities when possible. Do not add a large new infrastructure dependency if a simpler reliable solution already exists in this stack. Do not treat billing alerts as the application's rate-limiting system. After implementation: - test that normal intended usage still works - test that excessive repeated requests are rejected or throttled - document the limits you added and where they can be adjusted - list any provider-side spending limit or billing alert that I should configure manually Do not commit, push, or deploy.

Add a Provider-Side Cost Safety Net

For every paid API your application can trigger, open the provider dashboard. Where supported, do the following for the expensive services your project really uses.

Set a Spending or Usage Limit That Makes Sense for Your Launch Enable Billing or Usage Alerts Make Sure Alerts Go to an Email Address You Actually Monitor

Provider limits and billing alerts are a useful second layer. They do not replace protection inside your application.

Validate Inputs and File Uploads

Frontend validation is useful for user experience, but requests can be sent directly to your backend without using your form. The trusted validation must also happen on the server.

Harden Inputs, Rendering, URLs, and Uploads

Now audit and harden all places where this project accepts untrusted user-controlled data. Only implement protections relevant to features that actually exist. Check: 1. API request bodies, query parameters, route parameters, forms, search fields, profile fields, settings, and other user-controlled values. 2. Ensure important validation is enforced on the trusted server side, not only in the browser: - required fields - expected data types - length and size limits - allowed values/enums - numeric ranges - safe normalization where appropriate 3. Database access: - use parameterized queries, safe ORM/query APIs, or equivalent protections - do not construct unsafe database queries from raw user input. 4. User-generated content: - determine how the framework renders it - prevent script/HTML injection - do not introduce raw HTML rendering unless it is truly required - if rich HTML is intentionally supported, use an established sanitizer appropriate to the stack. 5. URLs supplied by users: - if the server fetches remote URLs, inspect for SSRF-style risks - restrict protocols, destinations, redirects, and network access appropriately for the feature. 6. File uploads, if present: - allow only file types actually needed by the product - enforce server-side size limits - do not trust only the filename extension or browser Content-Type - generate safe storage names instead of trusting user filenames - prevent path traversal/unsafe paths - verify upload/download authorization - ensure private files are not placed in a publicly readable location by accident - add deeper malware/content scanning only when appropriate to the risk and platform rather than inventing a fake scanner. 7. Avoid logging sensitive user input, passwords, authentication tokens, or private uploaded content unnecessarily. Preserve normal product behavior. After making the changes: - run the relevant tests/build - test invalid and oversized input - test upload rejection if uploads exist - list what was protected - clearly mark features that were not applicable Do not commit, push, or deploy.

Secure Payments and Webhooks

If the project does not accept payments and does not receive sensitive webhooks, skip this step.

Verify Payments and Webhooks

This project may contain payments or security-sensitive webhooks. Inspect them and fix only the issues that actually apply. For Stripe or another payment provider, verify: 1. Private payment-provider secret keys run only in trusted server-side code. 2. The browser cannot decide authoritative values such as: - whether payment succeeded - final amount - privileged plan/role - product entitlement - sensitive price or account ownership when those values should come from trusted server-side data or the payment provider. 3. Webhook requests are cryptographically verified using the provider's official mechanism before their contents are trusted. 4. For Stripe specifically: - verify the Stripe-Signature using the correct webhook endpoint secret - preserve the raw request body when required by Stripe's verification flow - reject invalid signatures. 5. Webhook processing safely handles duplicate/retried events so the same event cannot accidentally grant the same entitlement or perform the same sensitive side effect multiple times. 6. Use idempotency for payment-creation or other sensitive retryable operations where appropriate. 7. Test and live credentials/webhook secrets are not mixed. 8. Payment success pages do not grant access merely because the browser reached a success URL. 9. Relevant payment/webhook endpoints expose only the minimum information required in errors and logs. Make the smallest safe changes and use the provider's official SDK/patterns where the project already supports them. Then: - run relevant tests - tell me how to test the integration safely in test/sandbox mode - list any manual dashboard configuration still required If no payments or security-sensitive webhooks exist, make no changes and report NOT APPLICABLE. Do not commit, push, or deploy.

Add Stripe Subscriptions to Any Website with Supabase

Use this resource if Stripe still needs to be implemented or rebuilt properly. If your existing integration passed the checks above, continue with the security guide.

RESOURCE

https://profitstudio.app/video/add-stripe-subscriptions-supabase

Harden the Production Build

You have handled the highest-risk application logic. Before publishing, perform one production-focused cleanup and then a final read-only audit.

Production Security Hardening

Perform a final production-hardening pass on this project. You may modify files in this step, but focus only on concrete pre-launch security and production configuration issues that have not already been fixed. Check: 1. Dependencies: - use the appropriate audit/security tooling for this project's package manager - identify known vulnerabilities that actually affect installed dependencies - prioritize exploitable/high-impact production issues - avoid blindly upgrading every dependency or making unnecessary major-version migrations - apply the smallest compatible updates where appropriate and test them. 2. Production configuration: - development/debug modes disabled where appropriate - source or internal errors are not unnecessarily exposed to users - no development-only endpoints or tools are publicly enabled - environment-specific credentials/configuration are separated appropriately. 3. CORS: - do not use overly broad origins with authenticated or sensitive endpoints unless intentionally required - use an appropriate production allowlist where needed. 4. Sessions/cookies if applicable: - appropriate Secure, HttpOnly, SameSite, expiration, and framework-specific settings. 5. Security headers: - inspect what the framework/hosting layer already provides - add appropriate missing headers using established framework/platform mechanisms - do not introduce a restrictive CSP blindly if it will break legitimate application resources; configure and test it if used. 6. Logging and errors: - no secrets, passwords, tokens, sensitive authorization headers, full payment details, or unnecessary personal data in logs - user-facing errors do not expose stack traces or internal implementation details. 7. Public attack surface: - remove or protect unused test routes, debug endpoints, temporary admin tools, sample credentials, development utilities, or accidentally public storage. 8. Run the production build and the relevant automated tests after the changes. Do not redesign the application or make unrelated refactors. At the end provide: CHANGES MADE DEPENDENCY FINDINGS PRODUCTION CHECKS TEST RESULTS MANUAL ACTIONS STILL REQUIRED Do not commit, push, or deploy.

Run the Final Read-Only Security Review

This is your launch gate. The AI should now verify the finished project rather than continue making changes.

Final Pre-Launch Security Review

Perform the final pre-launch security review of the project in its current state. READ-ONLY REVIEW: - Do not modify any files. - Do not commit, push, or deploy. - Never print secret values. - Re-check the actual code and configuration. Do not assume previous fixes worked simply because they were attempted. - Run safe read-only checks, tests, and builds where useful. Verify these areas: 1. PRIVATE SECRETS No private credential is shipped to the browser, committed in an unsafe project file, returned through an API, or exposed through logs. Public-by-design credentials must not be incorrectly reported as secrets. 2. USER & ADMIN ACCESS Authorization is enforced on trusted server/database layers. A normal user cannot access another user's private records or admin-only actions simply by manipulating a URL, request, or identifier. 3. DATABASE ACCESS Data-access rules match the application's intended privacy model. For Supabase, verify relevant RLS, grants, and policies rather than judging security from the presence of a publishable/anon key. 4. API ABUSE Relevant expensive/public operations have reasonable authentication, rate/usage limits, size limits, or equivalent abuse controls. 5. UNTRUSTED INPUT Server-side validation exists where needed and unsafe rendering/query construction is not present. 6. FILES If uploads exist, type/size/storage/access controls are appropriate. 7. PAYMENTS & WEBHOOKS If present, private keys remain server-side, authoritative payment state is trusted from server/provider data, webhook authenticity is verified, and duplicate/retry behavior is handled safely. 8. PRODUCTION CONFIGURATION No obvious debug exposure, sensitive logging, dangerous CORS/session configuration, unnecessary public development endpoints, or unresolved high-impact production dependency vulnerability was found. 9. VERIFICATION Review available build/test results and any security-specific tests. Do not claim that a test passed if you did not actually run it or have evidence. Return exactly: FINAL STATUS Choose one: - PASS BASELINE - NEEDS ATTENTION - BLOCK LAUNCH LAUNCH BLOCKERS List only unresolved issues that could expose private credentials/data, allow unauthorized privileged actions, incorrectly trust payments/webhooks, or permit obvious uncontrolled abuse of sensitive/expensive operations. Write "None found" if none were confirmed. CHECKLIST Secrets: PASS / FAIL / N/A User isolation: PASS / FAIL / N/A Admin authorization: PASS / FAIL / N/A Database rules: PASS / FAIL / N/A API abuse protection: PASS / FAIL / N/A Input validation: PASS / FAIL / N/A File uploads: PASS / FAIL / N/A Payments/webhooks: PASS / FAIL / N/A Production configuration: PASS / FAIL / N/A Dependencies/build/tests: PASS / FAIL / N/A REMAINING NON-BLOCKING ITEMS Only genuine improvements worth tracking after launch. EVIDENCE Briefly state the important files/tests/configuration you checked. Do not describe the project as "100% secure" or claim that this review is a penetration test.

Decide Whether to Launch

PASS BASELINE

Your project passed this pre-launch baseline and no known launch blocker remains from these checks. You can move to deployment.

NEEDS ATTENTION

Review the remaining items. Fix anything that matters to your specific application before inviting a large number of real users.

IMPORTANT — BLOCK LAUNCH

Do not publish for real users yet. Return to the affected step, fix the blocker, and run the Final Pre-Launch Security Review again.

Recommended Hosting

Your application security and your hosting infrastructure are different layers. Good hosting can protect and operate the infrastructure around your project, but it cannot repair authorization mistakes, exposed private API keys, insecure database rules, or unsafe application logic inside your code. Once the project passes the security baseline, you can deploy the finished version.

Hostinger

Deploy your secured project with Hostinger and take it live when you're ready.

RECOMMENDED

https://www.hostg.xyz/SHJxF?source=guide_secure_ai_launch

Choose the Deployment Guide That Matches Your Project

Deploy Your Claude Code Project to Hostinger — The Safe Way

For a project built with Claude Code.

DEPLOY GUIDE

https://profitstudio.app/video/deploy-claude-code-projects

Deploy Google AI Studio Projects

For a project built with Google AI Studio.

DEPLOY GUIDE

https://profitstudio.app/video/deploy-google-ai-studio-projects

Verify the Production Version

After deployment, test the production version once more.

Sign In on the Production Version

Verify the Main Protected Workflow

Confirm Environment Variables Are Configured Correctly

Make Sure No Development-Only Behavior Appears in Production