# 8 Security Checks Before Launching Your AI-Generated App

> Check secrets, storage, database access, authentication, CORS, dependencies, and rate limits before launching an AI-generated app.

Published 2025-07-27. Canonical page: https://www.guvenkaya.co/blog/security-bites-top-eight-security-issues-llm-generated-apps

Before launching an AI-generated app, check how it handles secrets, user data, authentication, permissions, dependencies, and abuse. The checks below explain what to inspect and how to test it. They apply whether code was written by a person, an AI tool, or both.

## 1. Exposed API keys and secrets

**Risk:** A secret in frontend code, a public repository, or a log can give someone access to your services and data.

**What to check:** Keep server credentials in a secret manager or protected server environment. Distinguish secret keys from publishable keys intended for client use. Revoke and replace exposed credentials; deleting the file does not invalidate them.

**How to test:** Scan the repository and its history for secrets. Inspect the deployed frontend bundle and logs for credentials that should remain on the server.

## 2. Public access to private files

**Risk:** Storage permissions can expose uploads that users expect to remain private.

**What to check:** Make private user files inaccessible by default. Grant access only to the users and services that need it, including through temporary download links.

**How to test:** Upload a private file, then try to download it while signed out and while signed in as a different user. Check whether an expired download link still works.

## 3. Missing database access policies

**Risk:** A logged-in user may be able to read or change another user's records.

**What to check:** Define which users can select, insert, update, and delete each type of record. If your database uses row-level security, enable it and configure the policies; enabling it alone does not define the access your app needs. See the [Supabase RLS documentation](https://supabase.com/docs/guides/database/postgres/row-level-security).

**How to test:** Create two test accounts. Confirm that each can perform its permitted actions and cannot read, change, or delete the other's private records.

## 4. Authentication and authorization enforced only in the interface

**Risk:** Hiding an admin button or checking login state in the browser does not protect the underlying endpoint.

**What to check:** Verify sessions and permissions on the server for every protected operation. Use your authentication provider's supported server-side validation and configure additional protection for privileged accounts.

**How to test:** Call protected endpoints while signed out, with an expired session, and as a user without the required role. Confirm the server rejects each unauthorized request.

## 5. Incorrect cross-origin access settings

**Risk:** A CORS configuration that trusts an unintended origin can expose responses to scripts running on that site.

**What to check:** Allow browser cross-origin access only where the application requires it. CORS controls which origins browsers allow to read responses; it does not replace authentication, authorization, or CSRF protection. See the [MDN CORS documentation](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS).

**How to test:** Use a separate test origin to attempt browser requests to sensitive endpoints. Confirm that unauthorized origins cannot read the responses and that the server independently checks permissions.

## 6. Weak or reused credentials

**Risk:** Default passwords, predictable tokens, or reused secrets can let an attacker impersonate a user or service.

**What to check:** Remove default credentials, generate service secrets with a cryptographically secure generator, and use separate credentials for different environments. Configure password protections and multifactor authentication through your identity provider.

**How to test:** Check a fresh deployment for default accounts and credentials. Confirm that privileged accounts follow the intended authentication policy and that revoked credentials no longer work.

## 7. Vulnerable dependencies

**Risk:** A deployed library or framework may contain a known vulnerability affecting a feature your app uses.

**What to check:** Inventory direct and transitive dependencies. Review security advisories, update affected packages, and check that suggested packages come from the intended maintainers.

**How to test:** Run dependency scanning in your build process. After an update, rerun application tests and confirm that the deployed version includes the fix.

## 8. Missing limits on expensive or repeatable actions

**Risk:** Repeated login attempts, messages, uploads, or AI requests can exhaust resources, increase costs, or enable abuse.

**What to check:** Set limits for sensitive and expensive operations. Consider account, endpoint, and service-wide limits as well as IP limits, with appropriate quotas for paid services.

**How to test:** In a controlled environment, exceed each configured limit and check that requests are rejected as intended. Verify that legitimate users can continue using the application.

[Discuss an application security review](https://www.guvenkaya.co/contact?service=penetration-testing).