DEV Community

Cover image for I Let Claude Pentest My Own Side Project for $0.43. It Found Three Things in 12 Minutes.
Kiell Tampubolon
Kiell Tampubolon

Posted on

I Let Claude Pentest My Own Side Project for $0.43. It Found Three Things in 12 Minutes.

I built ContextForge to solve my own problem: AI chats that lose memory mid-project. Last night I gave Claude the codebase and asked it to find ways to break in. Twelve minutes and forty-three cents later, I had a finding sheet I would have been embarrassed to show a senior engineer.

This post is what I did, what it found, what it missed, and how to do the same to your own side project tonight without spending more than a dollar.

What I Built

ContextForge is a small open-source app for managing AI conversation context. Next.js on the front, FastAPI on the back, SQLite for storage. Roughly 4,200 lines of TypeScript and Python at the time of the audit. Personal project, not yet shipped, but already wired up to a real LLM API and already storing real conversation data on disk.

In other words, exactly the class of side project most developers never security-review. We treat side projects like sketches and production apps like buildings. The problem is that side projects ship to production constantly, often with the same database engine and the same secret-handling habits we'd use in a real product.

The Setup

I wanted a junior pentester for one evening. Not a vendor scanner, not a SaaS audit tool. Just a smart adversary with patience. So I gave Claude three things:

A clear adversarial role. "You are a senior application security engineer. Your job is to find ways an attacker could compromise this app, exfiltrate data, or escalate privileges. Be specific. Cite line numbers. Rank findings by severity."

The repo. I dumped the relevant files (FastAPI routes, the Next.js API handlers, the SQLite schema, the .env.example, the Docker setup) into the conversation.

Scope rails. "Focus on the API surface, secret handling, input validation, and storage. Skip dependency CVEs for this pass. Skip nice-to-haves. Only flag things that would matter if this app went public tomorrow."

The whole prompt was about 200 words. The repo dump was about 18,000 tokens. Total session cost on the Anthropic API: $0.43 across two back-and-forth rounds.

What It Found

Three findings. All real. All embarrassing in different ways.

Finding 1: API key leaking through error responses

My FastAPI exception handler returned the full exception message to the client on 500 errors. One of those exceptions, raised when the LLM client failed to authenticate, included the partial API key in its message. A debug aid I forgot was there. An attacker who could trigger that specific failure path would get back a fragment of my OpenRouter key in the JSON response.

# api/routes/context.py (the bug)
@router.post("/extract")async def extract_context(payload: ExtractRequest):
    try:
        result = await llm_client.extract(payload.text)
        return {"context": result}
    except Exception as e:
        # bug: this leaks internal error text including upstream API errors
        raise HTTPException(status_code=500, detail=str(e))
Enter fullscreen mode Exit fullscreen mode

The fix is one line of paranoia. Catch the exception, log the real error server-side, return a generic message to the client.

# api/routes/context.py (the fix)
@router.post("/extract")async def extract_context(payload: ExtractRequest):
    try:
        result = await llm_client.extract(payload.text)
        return {"context": result}
    except Exception as e:
        logger.exception("extract_context failed")
        raise HTTPException(status_code=500, detail="extraction failed")
Enter fullscreen mode Exit fullscreen mode

I had written this exact pattern correctly in three other routes. I missed it on this one because I was tired when I added it. This is the most common shape of a real vulnerability: not a clever attack, just a tired Tuesday.

Finding 2: SQLite path traversal in the per-project save feature

ContextForge lets you save context packs per project. I was using the project name as part of the file path. No sanitization. A project named ../../../etc/passwd would happily walk out of the data directory.

Claude flagged the exact line, suggested a deny-list (which I rejected because deny-lists always lose), and on follow-up suggested a UUID-based storage scheme where the user-facing name is decoupled from the on-disk path. That is the right answer. I was using the name because it was convenient during dev. Convenient during dev is the most dangerous phrase in security.

Finding 3: CORS set to wildcard in the FastAPI config

I had allow_origins=["*"] for "local development convenience" in a config file that was also being loaded in the Docker production target. If I had pushed this to a public deployment as-is, any website on the internet could have made authenticated requests to the API from a victim's browser. This is the kind of thing that gets caught by a real code review and almost never gets caught by a unit test.

What It Missed

This is the part most "I used AI for security" posts skip, and it's the part that matters.

Claude did not catch a race condition in the project deletion endpoint, where deleting a project while a context extraction was in flight would leave orphan rows in the embeddings table. I found that one myself two days later when something broke in the UI. It's the kind of bug that requires understanding the full data flow over time, not just reading individual files.

It also did not catch the fact that my rate limiter was applied per IP and my dev environment was running everything through localhost, meaning the rate limiter was effectively disabled for all real testing. A pentester who uses the app for a day would have noticed this. A model reading the code in isolation didn't.

The lesson isn't that AI security review is bad. The lesson is that it's a good first pass. It catches the ten things I should have caught myself before I shipped. It does not replace someone who actually uses the system over time.

The Cost Math That Surprised Me

Total tokens for the session: roughly 47,000 input, 8,200 output. Total cost on the Anthropic API: $0.43. Twelve minutes of wall-clock time. For comparison, the cheapest external code review I have ever paid for cost $300 and took a week.

That is not a fair comparison, of course. A human reviewer brings context and judgment Claude does not have. But for the specific job of "find the obvious things in my own code before I ship," forty-three cents is the right ballpark and twelve minutes is the right wall-clock.

I would happily pay this every time I'm about to push a side project to a public URL. I am, in fact, going to make it a checklist item.

What This Actually Teaches You

A frontier model is a free junior pentester on your own code, with two caveats. First, you must give it adversarial scope, not "review my code." The framing matters because models default to politeness, and a polite reviewer does not find leaks in error responses. Second, you must verify the findings yourself. The cost of acting on a false-positive is wasted time. The cost of acting on a real finding is one fewer embarrassment.

The post-mortem habit matters more than the tool. Every finding above was a thing past-me knew was wrong and present-me had stopped paying attention to. The audit was not new knowledge. It was a forced re-read with a hostile lens.

If you are sitting on a side project that has crept toward something real (a small SaaS, a portfolio piece with a live URL, a tool you started selling on the side), run this audit tonight. Forty-three cents and twelve minutes is the right price for sleeping better.

The Five-Step Checklist If You Want To Run This Tonight

Pick the project. Anything with a public URL or a real database counts.

Dump the security-relevant files into a fresh chat. API routes, config, env example, schema, auth middleware.

Use the adversarial prompt: senior application security engineer, find specific vulnerabilities with line numbers, ranked by severity, scoped to API surface and secrets and storage.

Read every finding. Verify against your code. Reject the false positives.

Fix the real ones before you sleep. Otherwise tomorrow you will not.


What is the smallest, most embarrassing thing an AI security review found in your own code? And what is the one finding you are still arguing with the model about because you don't want to fix it? Drop both in the comments. The most surprising answer becomes the next post, with credit.

Top comments (0)