Pentest & Audit 2026-10-07 8 min READ

Website Security Audit: 7 Critical Flaws That Leak Customer Data

Discover the 7 most dangerous web vulnerabilities that lead to severe customer data breaches and server compromise. Technical root causes, exploitation mechanics, and remediation code.

S By Site Check Security Team

The majority of catastrophic customer data breaches do not stem from complex, nation-state zero-day exploits. Instead, forensics reports consistently reveal that threat actors gain initial access through fundamental, preventable architectural flaws: forgotten debug endpoints, wide-open database ports, permissive CORS policies, or unparameterized queries that took fewer than ten seconds to exploit.

When customer Personally Identifiable Information (PII) or credit card details leak onto dark web forums, organizations face devastating GDPR/CCPA fines, severe reputational destruction, and crippling customer churn. Performing a targeted audit against these seven high-impact vulnerabilities is the single most effective way to safeguard your platform.

1. Flaw 1: Publicly Exposed Environment Files (.env, .git)

Leaving .env or .git repositories accessible in the web root remains one of the most prolific security disasters. Automated bot crawlers continuously scan for /.env, /.git/config, and /docker-compose.yml. When accessible, attackers extract production database credentials, Stripe private API keys, and JWT salts within seconds.

Comprehensive exclusion of environmental and backup files in Nginx

                  # Nginx configuration to deny access to sensitive dotfiles and backups
location ~* /\.(env|git|svn|htaccess|docker|aws) {
    deny all;
    access_log off;
    return 404;
}

location ~* \.(bak|config|sql|dump|old)$ {
    deny all;
    return 404;
}

2. Flaw 2: Direct Database Port Exposure (Postgres, Mongo, Redis)

Configuring a cloud virtual machine or container to expose PostgreSQL (5432), MongoDB (27017), or Redis (6379) to 0.0.0.0 enables remote actors to run credential brute-forcing or automated ransomware attacks. Databases must be bound exclusively to loopback addresses or internal private VPC networks.

Important Note: Redis running without password authentication on a public port allows attackers to write arbitrary SSH keys into /root/.ssh/authorized_keys via Redis commands, achieving instantaneous root Remote Code Execution (RCE).

3. Flaw 3: Broken Object-Level Authorization (BOLA / IDOR)

APIs frequently accept user-supplied resource identifiers (e.g. GET /api/orders/9482) without validating whether the requesting session owns the record. Attackers write automated enumeration scripts to scrape entire customer databases. Always incorporate tenant and user ownership assertions in data queries.

4. Flaw 4: Permissive Cross-Origin Resource Sharing (CORS)

Developers struggling with CORS errors often deploy wildcard configurations: Access-Control-Allow-Origin: * combined with Access-Control-Allow-Credentials: true. This allows any third-party website visited by your logged-in customer to forge authenticated requests and extract private API data on their behalf.

Strict origin validation in Express.js middleware

                  // Secure CORS implementation with strict origin whitelisting
import cors from 'cors';

const allowedOrigins = ['https://site-check.velar.plus', 'https://app.velar.plus'];

app.use(cors({
  origin: (origin, callback) => {
    if (!origin || allowedOrigins.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error('Rejected by CORS policy'));
    }
  },
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
}));

5. Flaw 5: SQL & NoSQL Injections via Raw Parameter Concatenation

Concatenating user input directly into database queries remains a persistent vulnerability. Always utilize parameterized prepared statements or trusted Object-Relational Mappers (Prisma, Drizzle, TypeORM) to guarantee untrusted inputs are treated strictly as data literals rather than executable commands.

6. Flaws 6 & 7: Insecure Cookie Flags & Verbose Debug Output

Transmitting session cookies without HttpOnly (allowing client-side XSS cookie theft), Secure (allowing interception over unencrypted HTTP), and SameSite=Lax (leaving users vulnerable to CSRF) severely compromises session integrity. Additionally, printing raw database stack traces on 500 errors hands attackers complete architectural blueprints.

Developer Security Checklist

✓ Block public HTTP requests to all dotfiles (/.env, /.git, /.aws)
✓ Bind internal databases (Postgres, Mongo, Redis) strictly to 127.0.0.1
✓ Validate tenant/user ID ownership in every backend data retrieval controller
✓ Replace wildcard CORS origins with strict domain whitelists
✓ Enforce HttpOnly, Secure, and SameSite attributes on all session cookies
✓ Disable verbose debug error output and stack traces in production builds

Security Auditor Synthesis & Key Takeaways

When shipping production web applications and vibe-coded projects built on modern stacks (Next.js, Astro, React, Supabase), perimeter security cannot be an afterthought. Over 85% of customer data leaks and database compromises do not stem from sophisticated zero-day exploits, but rather from trivial misconfigurations: orphaned staging endpoints, exposed environment files, overly permissive CORS policies, and disabled Row Level Security (RLS) rules.

Automated perimeter scanning with Site Check proactively catches these signatures across 36 critical attack vectors, equipping engineering teams and vibe-coders with immediate actionable remediation guides before automated scanning botnets discover the exposed endpoints.

Recommended Guides

Pentest & Audit