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 may require changes to application design, code, or configuration. Learn how to secure your data flows, implement server-side authorization, and configure essential security headers.

By Gabriel CA · Kraftwire Software

Architecture security review examines trust boundaries, credentials, authorization, and resource use. Exposed database credentials or missing limits may require changes to code, configuration, or design. Choose controls for the application’s access model, then test them.

These live figures describe all scanned sites. They do not establish prevalence for an AI-built subgroup, compare development methods, or attribute findings to AI generation.

11% of the 119 live sites SimplyScan has scanned (13 sites) have at least one medium-severity architecture issue, such as a library with a known vulnerability or no rate limiting.

Why Do Architecture Risks Go Beyond Code Vulnerabilities?

Architecture decisions determine data flows, trust boundaries, and failure handling. Review these alongside code-level issues such as injection and exposed secrets; repairs may involve code, configuration, or both.

A browser may use a public data API when the server enforces appropriate authorization. A database credential with broad privileges does not belong in browser code. Review the boundary and permissions rather than treating every client-to-data-service connection as unsafe. See the vibe coding checklist.

30% of the 119 live sites SimplyScan has scanned (36 sites) have at least one high or critical security issue.

Why Are Exposed Database Connection Strings So Dangerous?

Inspect how credentials are stored and which components can access them, including apps built with Cursor or Lovable.

What a Connection String Reveals

A typical database connection string looks like this:

This example contains a username, password, hostname, port, and database name. The hostname and port identify a connection target; they do not prove that the service is reachable or reveal its physical location.

How Connection Strings Can Be Exposed

A credential included in a client bundle can be read by visitors. Inspect built assets and responses, not just the source file where the credential was first configured.

If a .env file containing credentials was committed, deleting the current file does not remove earlier commits or other copies. Revoke exposed credentials and inspect history and ignore rules, including projects built with Windsurf or Bolt.new.

The Damage Potential

A usable leaked credential may allow reads, writes, or destructive operations such as DROP DATABASE, according to its database privileges and network access. Investigate what that account can reach; the string alone does not grant control over every table or other systems.

How to Fix It

• Keep credential-bearing connection strings out of client code. Use .gitignore to exclude local secret files, while separately checking already tracked files and build output.
• Load credentials from server-side secret storage.
• Revoke leaked credentials and update legitimate uses.
• Use separate database accounts with only the privileges required.
• Configure encrypted connections with certificate verification appropriate to the service.

Connection pooling can help manage connections, but does not replace these access controls.

What Happens When Your App Has No Rate Limiting?

Rate limiting bounds requests according to a chosen identity, endpoint, or resource. It can reduce abuse, but is not complete denial-of-service protection.

Choose Limits for the Application

Choose limits using expected traffic, request expense, and abuse scenarios. Consider authenticated users, IP addresses, and service-wide budgets; an IP alone may represent many legitimate users.

What Attackers Do Without Rate Limits

• Brute force: Repeated password guesses.
• Credential stuffing: Attempts with credentials leaked from other services.
• API abuse: Repeated expensive requests or unintended data collection.
• Enumeration: Requests such as /api/users/1 and /api/users/2 that probe resource identifiers. Authorization remains necessary even when requests are limited.

How to Implement Rate Limiting

At the application level: The original in-memory example below illustrates a windowed counter. It is local to one process, resets on restart, retains map entries, and needs validation of limits and a trustworthy client identifier. It is not a complete distributed or production rate limiter.

Choose endpoint-specific limits: Test login, registration, password reset, search, and expensive operations under expected usage. There is no universal request count that secures every application. Monitor rejected requests and adjust without allowing attackers to lock out legitimate users.

At the infrastructure level

Evaluate rate controls and denial-of-service protections available from your hosting or edge provider. Test how those controls identify clients and interact with application-level limits. A CAPTCHA can add friction but does not replace authorization or usage limits.

Why Is Relying on Client-Side Security Dangerous?

Frontend controls determine what the interface displays. They cannot enforce access to a server operation. Review authorization at the component that serves the data or performs the action.

How This Manifests

Hiding UI elements instead of enforcing access control:

Hiding the component does not establish authorization for an endpoint such as /api/admin/delete-user. Test direct requests using curl or another client; the server must reject calls outside the caller’s permissions.

Client-side data filtering:

This deliberately insecure pattern assumes the endpoint returned an array containing other users’ private orders. Filtering that array in the browser cannot undo the disclosure. The example omits error and schema handling; it demonstrates why filtering must occur before private data is returned.

Enforce Access Before Returning Data

• Authentication: Validate the identity required by the endpoint using JWTs or the chosen session mechanism.
• Authorization: Check the caller’s permission for the operation and records, using server logic or controls such as Supabase RLS.
• Data Filtering: Return only authorized records. A parameterized query such as SELECT * FROM orders WHERE user_id = ? must bind an identity established by the server, not an unchecked client value.
• Input Validation: Validate requests on the server even when the frontend also checks them.

Which Security Headers Does Your App Need?

Security response headers configure browser behavior. Their effect depends on the header value, browser support, and application context. Test the deployed policy alongside application controls.

Headers to Review

• Content-Security-Policy: Restricts supported resource loading and framing behavior; an effective policy can reduce some injection effects.
• Strict-Transport-Security: Instructs supporting browsers to use HTTPS once the policy is known, including through applicable preload entries.
• X-Frame-Options: Restricts framing in supporting browsers.
• X-Content-Type-Options: Configures MIME-type enforcement for supported resource contexts.
• Referrer-Policy: Controls the referrer information sent with requests.

Headers may be set by application code, the web server, or a proxy/CDN. Inspect the final response because layers can add, remove, or override them.

Why Is a Single API Key for Everything Risky?

A credential used across unrelated operations can grant more access than any one component needs. Limit its scope and separate credentials where appropriate. A leak’s impact depends on the permissions and services the credential can access.

Secret Management

• Frontend: Use only keys designed for public clients, paired with server-enforced access controls.
• API Routes: Use the narrowest service permissions needed.
• Admin Functions: Keep privileged credentials server-side and authorize each caller.
• Environments: Separate credentials to limit unintended access between development, staging, and production.

Scan deployed assets and repositories for detectable secret patterns. Investigate findings and revoke exposed credentials; a clear result does not prove that no secrets remain. See the secret scanner.

Why Does Your App Need Security Logging and Monitoring?

Security logs and monitoring support detection and incident investigation. Their coverage and retention determine what they can reveal; absent application logs do not mean every attack is undetectable.

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

• Keep database credentials out of client bundles.
• Test usage limits for sensitive or expensive endpoints.
• Enforce authentication where required and authorization for protected operations.
• Configure relevant browser headers and inspect deployed responses.
• Scope credentials to the services and environments that need them.
• Monitor security-relevant events without recording secrets.
• Keep internal diagnostics out of public error responses.
• Validate file uploads and control how they are stored, served, and processed.

How Do You Scan Your Architecture for Vulnerabilities?

SimplyScan checks publicly observable signals such as recognizable secret patterns, security headers, and supported anonymous backend responses. It does not verify every rate limit, private authorization path, or architecture decision. Review the code and test authenticated behavior separately.

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

Related Guides

• Performance as a Security Risk
• CSRF Protection and Security Headers
• Supabase Security Checklist
• Security Audit Checklist

Related free tools

• CORS Tester · Inspect supported cross-origin response headers and preflight behavior.
• Security Headers Checker · Inspect returned security headers.
• Secret Scanner · Check supported inputs for recognizable secret patterns.

Browse our free tools.