I Audited My Own Code. 19 Security Findings Later...

I do security reviews professionally. When I finished building a custom analytics dashboard for this site, I did what I always tell clients to do: I audited my own work.

19 findings.

Not minor stuff. Query-string authentication that leaked secrets into browser history. An SSRF vector that could probe internal networks. Error messages that handed attackers my database schema. The kind of issues I'd flag as HIGH or CRITICAL in a client report.

The irony wasn't lost on me. I shipped this code. I'm the one who advocates for "build security in from the start." And yet, when I was moving fast with Claude Code, building features and solving problems, I made the same mistakes I see in every rapid development cycle.

This post is the story of that audit. Not a checklist, not a tutorial. Just the journey from "it works" to "it's defensible."

The Scope#

Before diving into code, I started where a threat actor would start: reconnaissance.

What's publicly visible? What can be learned without touching the application?

I reviewed:

• All blog posts on this site
• The public GitHub repository
• Information disclosed in examples, error snippets, and architecture explanations

The goal was to map what an adversary knows before they even send their first request.

Phase 1: Information Disclosure Audit#

From a threat actor's perspective, published content is gold. Blog posts, documentation, and example code reveal patterns, dependencies, and internal structure.

Most of these are LOW risk individually. Knowing I use Neon Postgres doesn't give an attacker access. Seeing environment variable names doesn't reveal their values.

But the pattern matters. Every piece of disclosed information reduces the attack surface an adversary needs to explore. The private repository names were the most actionable finding. An attacker now knows those repos exist and can monitor for accidental public exposure or credential leaks in other contexts.

Phase 2: Authentication (CRITICAL)#

/analytics?secret=YOUR_SECRET&days=30

Here's why query-string authentication is a problem:

1. Browser history. Every visit logs the full URL, including the secret. Anyone with access to the browser can see it.
2. Server logs. Web servers log request URLs by default. The secret ends up in access logs, error logs, and any log aggregation systems.
3. Referer headers. If the dashboard links to external resources (images, scripts, stylesheets), the secret leaks in the Referer header sent to those third parties.
4. Analytics and monitoring tools. Any client-side analytics (Vercel Analytics, in this case) may capture the full URL.

The fix: HMAC-SHA256 cookie-based authentication.

Here's the core of the implementation:

import { createHmac, timingSafeEqual } from "crypto";

export const ANALYTICS_COOKIE_NAME = "analytics_session";
const TOKEN_PAYLOAD = "analytics-authenticated";

export function generateAuthToken(secret: string): string {
  return createHmac("sha256", secret).update(TOKEN_PAYLOAD).digest("hex");
}

export function verifyAuthToken(token: string): boolean {
  const expectedSecret = process.env.ANALYTICS_SECRET;
  if (!expectedSecret || !token) return false;
  const expected = generateAuthToken(expectedSecret);
  try {
    return timingSafeEqual(Buffer.from(expected), Buffer.from(token));
  } catch {
    return false;
  }
}

The login flow:

1. User visits /analytics/login and submits the secret via POST (not GET).
2. Server validates the secret using constant-time comparison and generates an HMAC token.
3. Token is set as an httpOnly cookie:

response.cookies.set(ANALYTICS_COOKIE_NAME, token, {
  httpOnly: true,
  secure: process.env.NODE_ENV === "production",
  sameSite: "strict",
  path: "/",
  maxAge: 60 * 60 * 24 * 7, // 7 days
});

Now, every request to /analytics checks for the cookie:

import { cookies } from "next/headers";

const cookieStore = await cookies();
const token = cookieStore.get(ANALYTICS_COOKIE_NAME)?.value;

if (!token || !verifyAuthToken(token)) {
  redirect("/analytics/login");
}

Phase 3: Input Validation and Rate Limiting#

The tracking endpoint (/api/analytics/track) accepted any POST request. No validation on the pagePath parameter, no deduplication, no rate limiting.

The first fix: validate the input.

if (
  typeof pagePath !== "string" ||
  pagePath.length > 500 ||
  !pagePath.startsWith("/")
) {
  return NextResponse.json({ error: "Invalid path" }, { status: 400 });
}

This enforces three things: pagePath is a string, it's under 500 characters (prevents storage abuse), and it starts with / (prevents off-site paths from polluting analytics).

The second fix: deduplicate requests by IP and path.

A bot or malfunctioning script could send thousands of requests for the same page from the same IP. Each would create a new database row, inflating metrics and burning through Neon's free-tier query budget.

const existing = await sql`
  SELECT 1 FROM page_views
  WHERE ip_address = ${ipAddress}
    AND page_path = ${pagePath}
    AND visited_at > NOW() - INTERVAL '1 hour'
  LIMIT 1
`;

if (existing.length > 0) {
  return new NextResponse(null, { status: 204 });
}

Phase 4: SSRF Prevention#

The IP intelligence endpoint (/api/analytics/ip-intel) queries external APIs to get geographic and network information about visitor IPs. It powers the OSINT panel on the analytics dashboard.

In this case, the risk is limited because the external API returns geographic data, not raw HTTP responses. An attacker couldn't use this specific endpoint to exfiltrate data directly. But the pattern is dangerous. If the endpoint ever changed to query a different service, or if an upstream API accepted more complex queries, the SSRF vector could become a real compromise path.

The fix: validate that the IP address is public before making any external request.

function isPrivateIp(ip: string): boolean {
  // Checks against RFC 1918 private ranges, loopback,
  // link-local, and IPv6 equivalents
  if (/^127\./.test(ip)) return true;          // Loopback
  if (/^10\./.test(ip)) return true;           // Class A private
  if (/^192\.168\./.test(ip)) return true;     // Class C private
  if (/^172\.(1[6-9]|2[0-9]|3[0-1])\./.test(ip)) return true;
  // ... additional RFC 6598 and IPv6 checks omitted
  return false;
}

Phase 5: Error Message Sanitization#

catch (error) {
  return NextResponse.json(
    { error: "Query failed", details: error.message },
    // Client would see: { error: "Query failed", details: "[internal schema and path details]" }
    { status: 500 }
  );
}

The fix: log detailed errors server-side, return generic messages to clients.

catch (error) {
  console.error("Analytics query error:", error);
  return NextResponse.json(
    { error: "Failed to load analytics" },
    { status: 500 }
  );
}

This was applied across all API routes. The full error is still available in server logs for debugging. The client sees nothing useful for reconnaissance.

Phase 6: Setup Endpoint Hardening#

The /api/analytics/setup endpoint initializes the database schema. It's necessary for first-time deployment, but dangerous if left accessible in production.

if (process.env.ANALYTICS_SETUP_ENABLED !== "true") {
  return NextResponse.json(
    { error: "Setup endpoint is disabled" },
    { status: 403 }
  );
}

This follows the principle of secure by default. Dangerous operations require explicit opt-in.

Summary of Findings#

Total: 19 individual issues across these categories.

Lessons Learned#

What's Next#

The dashboard is defensible. Authentication is cryptographically sound. Input validation prevents abuse. SSRF vectors are closed. Error messages don't leak internal details.

But security isn't a destination. Future work includes automated dependency scanning, comprehensive per-endpoint rate limiting, and moving schema initialization to a deployment script. The analytics system is a living project, and the security posture needs to evolve with it.

For now, it's live, it's useful, and it's not a liability. That's the standard.

Written by Chris Johnson and edited by Claude Code (Opus 4.6). The full source code is at github.com/chris2ao/cryptoflexllc. This post is part of a series about AI-assisted development. Previous: Building Custom Analytics: Audience Intelligence for a Public Website. Next: Making Claude Code Talk: Terminal Bells and the Stop Hook.