Architecture Security Risks: Exposed Database Strings, Missing Rate Limiting & More

Quick answer: Architecture security risks are structural flaws like exposed database strings or missing rate limits that no code-level patch can fix. In SimplyScan's research of 170 AI-built apps, 48% suffered from architecture issues. Learn how to secure your data flows, implement server-side authorization, and configure essential security headers.

By Gabriel CA · Kraftwire Software

2026-02-14 · 8 min read

Architecture security risks are structural flaws in how an application is designed, such as exposing database connection strings in frontend code, omitting rate limits on sensitive endpoints, or relying on client-side logic for authorization. Unlike a simple code bug, an architectural risk often requires a fundamental redesign of data flows or infrastructure to fix.

Why Do Architecture Risks Go Beyond Code Vulnerabilities?

Most security guides focus on code-level issues like XSS, injection, and exposed secrets. Those are important. But some of the most dangerous vulnerabilities come from how your application is put together, not from individual lines of code. Architecture decisions determine how data flows through your system, who can access what, and what happens when things go wrong. Bad architecture creates vulnerabilities that no amount of code-level security can fix.

For example, if your architecture allows a frontend client to talk directly to a production database, no amount of input sanitization will prevent a malicious user from attempting to bypass your application logic entirely. This is why vibe coding security requires a shift in focus from "does the code work?" to "is the structure resilient?"

Why Are Exposed Database Connection Strings So Dangerous?

This is the most critical architecture issue we encounter. AI-generated apps frequently include database connection strings in frontend code or environment variables that get bundled into the client. When tools like Cursor or Lovable generate a full-stack scaffold, they often prioritize immediate functionality, which can lead to "leaky" configurations.

What a Connection String Reveals

A typical database connection string looks like this:

This single string contains:

Username and password for direct database access.
Server hostname revealing your infrastructure provider and location.
Port number confirming the service is accessible (usually 5432 for Postgres or 3306 for MySQL).
Database name identifying the specific production data store.

Why This Happens in AI Development

AI coding tools generate the simplest working connection. When you ask for database functionality, the AI puts the connection string where the code needs it. If that code runs in the browser (e.g., a React or Vue component), the connection string is publicly visible to anyone who opens the "Network" tab in Chrome DevTools.

Even in server-side code, connection strings often end up committed to git repositories. The AI generates a working .env file, the developer commits it, and the credentials are now in the git history permanently. This is a common pitfall when using Windsurf or Bolt.new if the user isn't careful about .gitignore rules.

The Damage Potential

With a database connection string, an attacker can:

Read all data in every table, including user credentials, payment information, and private messages.
Modify records including changing prices, granting admin access, or altering transaction histories.
Delete entire databases with a single DROP DATABASE command.
Use the server as a pivot point to attack other systems on the same network.
Exfiltrate data slowly over time, making detection difficult.

How to Fix It

Never include database connection strings in frontend code.
Store connection strings in environment variables that are only accessible server-side.
Use connection pooling services (like Supabase, PgBouncer, or RDS Proxy) instead of direct connections.
Rotate database passwords regularly.
Use separate database users with limited permissions (Least Privilege) for different parts of your application.
Enable SSL/TLS for all database connections to prevent man-in-the-middle attacks.

What Happens When Your App Has No Rate Limiting?

Rate limiting controls how many requests a client can make in a given time period. According to CyCognito, API security is the practice of protecting the integrity of APIs from threats to their confidentiality and availability. Without rate limiting, your application's availability is at constant risk.

Why AI-Generated Apps Skip Rate Limiting

AI coding tools focus on making features work. Rate limiting is an infrastructure concern that requires understanding traffic patterns, choosing appropriate limits, and implementing the limiting logic. AI models rarely add this automatically because it adds complexity to the "vibe" of the initial build.

What Attackers Do Without Rate Limits

Brute force attacks: An attacker tries thousands of password combinations per minute against your login endpoint.
Credential stuffing: Attackers use lists of leaked username/password combinations from other services to see if they work on your site.
API abuse: An attacker calls your API endpoints thousands of times per second to scrape your database or burn through your OpenAI/Stripe API quotas.
Enumeration attacks: Repeatedly calling endpoints like /api/users/1, /api/users/2 to discover valid user IDs or email addresses.

How to Implement Rate Limiting

At the application level:

Recommended limits by endpoint type:

Login: 5 attempts per minute per IP.
Registration: 3 accounts per hour per IP.
Password reset: 3 requests per hour per email.
General API: 100 requests per minute per user.
Search: 30 queries per minute per IP.

At the infrastructure level:

Use Cloudflare, AWS WAF, or Vercel's built-in firewall for DDoS protection.
Configure your CDN to rate limit by IP address before the request even hits your server.
Implement CAPTCHA on public-facing forms after 3 failed attempts.

Why Is Relying on Client-Side Security Dangerous?

One of the most dangerous architectural patterns is relying on the frontend for security decisions. AI-generated apps frequently implement access control in the UI rather than on the server. This is a primary cause of broken access control.

How This Manifests

Hiding UI elements instead of enforcing access control:

The admin panel component might be hidden from the UI, but the API endpoints it calls (e.g., /api/admin/delete-user) are still accessible. An attacker can call those endpoints directly using curl or Postman without ever seeing the UI.

Client-side data filtering:

The API returns all orders for all users. The frontend filters them. But the complete dataset travels over the network and is visible in browser DevTools. This is a massive data leak.

The Fix: Server-Side Everything

Every security decision must happen on the server:

Authentication must be verified on every API request using JWTs or session cookies.
Authorization must check permissions (e.g., Supabase RLS) on the server before returning data.
Data filtering must happen in the database query (e.g., SELECT * FROM orders WHERE user_id = ?).
Input validation must happen on the server, even if the frontend also validates for UX.

Which Security Headers Does Your App Need?

Security headers are HTTP response headers that tell browsers how to handle your content. They prevent entire classes of attacks at the browser level. Most AI-generated apps ship with zero security headers configured.

Essential Headers Every App Needs

Content-Security-Policy (CSP): Prevents XSS by controlling which scripts can execute. See our CSP guide.
Strict-Transport-Security (HSTS): Forces HTTPS connections.
X-Frame-Options: Prevents clickjacking by blocking iframe embedding.
X-Content-Type-Options: Prevents MIME sniffing attacks.
Referrer-Policy: Controls information leakage through referrer headers.

Security headers are an infrastructure concern. They need to be configured at the web server (Nginx/Apache) or CDN (Vercel/Cloudflare) level. This makes them one of the highest-impact security improvements you can make with minimal code changes.

Why Is a Single API Key for Everything Risky?

AI-generated apps often use a single "Master" API key for everything. This violates the Principle of Least Privilege.

Proper Secret Management

Frontend: Use only "publishable" or "anon" keys.
API Routes: Use restricted keys that only have access to specific tables or services.
Admin Functions: Use separate, highly protected credentials.
Environments: Development, staging, and production should never share keys.

Why Does Your App Need Security Logging and Monitoring?

AI-generated apps almost never include security monitoring. Without logging, you cannot detect attacks, investigate incidents, or understand how your application is being used.

What to Log

Authentication events: Login attempts, failures, and password changes.
Authorization failures: Users trying to access resources they should not.
Unusual patterns: High request rates or geographic anomalies.
Error rates: Sudden spikes might indicate an automated attack or injection attempt.

What Not to Log

Passwords (even failed ones).
Full credit card numbers.
Session tokens or JWTs.
Personal health information (PHI).

Architecture Security Checklist

No database connection strings in frontend code or client bundles.
Rate limiting configured on all sensitive endpoints (Login, API, Search).
All security decisions enforced server-side (Auth/AuthZ).
Security headers (CSP, HSTS, etc.) configured on all responses.
Separate API keys and credentials for each service and environment.
Authentication verified on every API request.
Authorization checked before every data operation (e.g., RLS).
Monitoring and logging implemented for security events.
Error messages do not reveal architecture details (e.g., stack traces).
File uploads validated, scanned, and sandboxed.

How Do You Scan Your Architecture for Vulnerabilities?

SimplyScan checks for architecture-level vulnerabilities including exposed connection strings, missing rate limiting indicators, client-side security reliance, and missing security headers.

Scan your app now · One free scan grades 8 dimensions in ~30 seconds.

Related Guides

Related free tools

CORS Tester · Test whether your API leaks data to any origin.
Security Headers Checker · Verify your CSP and HSTS configuration.
Secret Scanner · Find exposed keys in your public code.

Browse all 60 free tools.

Frequently asked questions

What can an attacker do with a leaked database connection string?

A connection string contains the username, password, host, and database name. If leaked, an attacker can read all tables, modify records (like admin flags), or delete the entire database. SimplyScan's research shows that 30% of AI-built apps contain high-severity issues like these exposed credentials in frontend code.

Is hiding the admin panel from non-admin users enough security?

No. Hiding UI elements is a UX choice, not security. The underlying API endpoints remain accessible. An attacker can call them directly via terminal or script. All authorization—checking if a user has the 'admin' role—must be performed on the server or via database policies like Supabase RLS.

What rate limits should I use for login and signup endpoints?

Standard best practices suggest: 5 login attempts per minute per IP, 3 registration attempts per hour, and 100 general API requests per minute. For AI apps, rate limiting is critical to prevent attackers from burning through your LLM API quotas or scraping your entire database through open endpoints.

Do security headers matter if my application code is already secure?

Yes. Headers like Content-Security-Policy (CSP) and HSTS provide a second layer of defense. CSP can stop an XSS attack even if your code has a vulnerability, while HSTS prevents man-in-the-middle attacks. SimplyScan detects missing headers that leave vibe-coded apps vulnerable to browser-level exploits.

What is the principle of least privilege for API keys?

Least privilege means each part of your app only has the keys it needs. The frontend should only have 'public' keys. Your backend should use restricted service keys. This limits the blast radius; if one key is leaked, the attacker doesn't get access to your entire infrastructure.

What should I never write to my application logs?

Never log sensitive data like passwords, session tokens, or full credit card numbers. Do log security-relevant events: failed login attempts, authorization denials, and spikes in error rates. These logs are essential for detecting active attacks that automated scanners might miss during a single pass.