DEV Community: ONE FANCY APPS

Your AI Wrote the App in a Weekend. Who's Watching It Now?

ONE FANCY APPS — Sun, 23 Aug 2026 12:51:59 +0000

Most security tools for AI-generated code stop at the scan. Here's the gap that leaves open, and why it costs you after you ship, not before.
There's a strange blind spot in how we secure the software we're building right now.

The tooling has raced to meet the moment. You vibe-code an app in a weekend with Cursor or Claude Code, and there's a whole category of scanners ready to read your repo, hand you a grade, and generate a fix prompt you can paste straight back into your editor. That's genuinely useful, and it catches real problems: hardcoded keys, injection, the classic OWASP mistakes that AI reproduces because they're all over its training data.

But watch what every one of those tools does the moment your app goes live: nothing.

They read the code once. They score it once. And then they go blind, exactly when the app starts taking real traffic from real people, some of whom are not friendly.

The problems that only exist at runtime

A code scan is a photograph. It captures a moment. But the vulnerabilities that actually drain accounts and leak databases don't always live in a single line of code you can photograph. A lot of them only exist when the app is running.

Consider the ones no static scan reliably catches:

Broken authorization. Your endpoint fetches /orders/42. The code looks fine. It compiles, it passes the demo. What the code doesn't show is that it never checks whether the logged-in user actually owns order 42. That flaw is invisible on paper and obvious the first time someone increments the number in the URL.

Abused endpoints. Your login route works perfectly. It also has no rate limit, because your prompt said "build login," not "build login that survives 10,000 credential-stuffing attempts an hour." The scanner sees working code. The attacker sees an open door.

The silence problems. Your SSL certificate expires on a Saturday. Your site goes down at 3am and comes back before anyone notices, except it happened twelve times this month. A dependency you stopped using two refactors ago still ships in every build and still has to compile, so a bad merge that drops a syntax error into it can break your whole test suite from code nobody even calls anymore.

None of that is in the repo snapshot. All of it is in the running system. And the running system is the part almost nobody is watching.

Why the gap exists

The gap isn't incompetence, it's specialization. Code scanning and runtime protection are genuinely different disciplines with different architectures, so they grew up as different products. You bought a scanner from one company, a WAF from another, uptime monitoring from a third, SSL alerts from a fourth, and a compliance tool from a fifth.

That was fine when the person shipping software was a team with a budget and someone whose job was to stitch those five tools together. It is not fine now, when the person shipping software is one founder, or a two-person team, or a developer who described a feature in English and accepted whatever the model wrote. That person is not going to assemble a five-tool security stack. They're going to ship with nothing, and find out what they missed from a customer, or from a bill.

The enterprise had a security team to cover the gap between "scanned" and "safe in production." The solo builder has no such team. Their version of a security team has to be automation with good defaults, running from the moment the code is written to long after it's deployed.

What closing the gap actually looks like

The fix isn't a better scanner. It's refusing to stop at the scan.

That means treating the whole path from commit to production as one continuous thing to watch. Scan the code and the repo for the vulnerabilities and leaked secrets, yes, but then keep going: put a managed firewall in front of the running app that blocks the injection attempts and the bots and rate-limits the login route, watch uptime and SSL and domain expiry so the silent failures stop being silent, and make the alert loud enough that a real incident actually reaches a human instead of dying in an inbox at 3am.

This is the thinking behind Defen.so, which is the reason I'm writing about the gap at all. It's built to cover that full path in one place: vulnerability and secret scanning across repo and live site, an automated pentest that grades your app A to F with paste-ready fixes, a managed WAF with rate limiting, and uptime, SSL and domain monitoring after deploy. It hooks into AI coding workflows over MCP, so the scanning runs inside Cursor, Claude Code and Windsurf as the code is written, and then keeps watching once it ships. There's a free tier, and the core packages are open source, so you can read exactly what it does rather than take a security vendor's word for it.

But the tool matters less than the principle, and I'd rather you take the principle even if you never touch the product: a one-time scan is a photograph of a moving thing. The security of software built this fast can't be a snapshot. It has to be a continuous watch, from the first line the model writes to the certificate that expires eight months after you forgot the project existed.

The uncomfortable part

There's a wave coming that will make this gap expensive to have ignored. Insurers are starting to ask where your code came from. Regulators are drafting vulnerability-reporting duties. Procurement teams are adding "was this AI-generated, and how did you secure it" to their questionnaires. The builders who set up continuous, ambient security now will treat those changes as paperwork. The ones who shipped a weekend project with a single scan and called it safe will treat them as a crisis, discovered mid-incident.

Vibe coding won. The speed isn't going back, and honestly it shouldn't, it's the best thing to happen to building software in a decade. The only open question is whether the watching catches up to the shipping.

Ship fast. Then watch everything. And make sure the thing watching doesn't stop the moment your app goes live, because that's the exact moment it starts to matter.

Vibe Coding Security in 2026: The Complete Guide for Developers Shipping AI-Generated Code

ONE FANCY APPS — Tue, 04 Aug 2026 17:04:16 +0000

I've been building software for 17 years. I have never seen the distance between "idea" and "deployed to production" collapse the way it has in the last two years.

You describe a feature in plain language. Claude Code, Cursor or Windsurf writes it. You skim, you accept, you ship. People are launching real products with real users and real payment flows in a weekend. This is vibe coding, and I mean this sincerely: it's wonderful.

It's also producing the least reviewed code in the history of our industry, at the highest volume, deployed by the least security-experienced builders we've ever had.

That combination is not a moral failing. It's a governance gap, and closing it is what this guide is about. I've written a deeper version of this thinking on the defen.so blog if you want to go further after this one.

Why Vibe Coding Security Is Different: Old Vulnerabilities at AI Speed

Here's what security vendors get wrong when they panic about AI code: the vulnerabilities aren't exotic. Independent testing of AI-generated code keeps finding the same classics. Close to half of generated samples in large studies carry OWASP Top 10 weaknesses. The usual suspects:

Hardcoded secrets. The API key pasted into the file "just to test," then committed. AI agents do this constantly because your prompt said make it work, not make it safe.
Missing authorization checks (IDOR). The endpoint fetches /orders/{id} and never asks whether the logged-in user owns that order. It works in every demo. It leaks every customer's data in production.
Injection. String-concatenated SQL and shell commands still show up in generated code, because they show up in the training data.
No input validation, no rate limits. The agent builds the login route. It does not build the brute-force cap, because you didn't ask.
Business logic flaws. The discount code that can be applied twice. No scanner is shaped to see these, and no AI agent flags its own.

None of this is new. What's new is the rate. A human developer introduces vulnerabilities at typing speed. An agent introduces them at generation speed, and a busy builder accepts them at scrolling speed.

So the question changed. It's no longer "is this code vulnerable?" It's "how fast are vulnerabilities entering, and does anyone see them before an attacker does?"

The 3 Windows Where AI-Generated Code Gets Exploited

When I look at where vibe-coded projects actually get burned, it's almost always one of three windows.

Window 1: Authorship. The flaw is written and accepted in the same minute. The person in the loop can't evaluate what they can't recognize. That's not an insult, it's just the reality of who is building now. The fix has to live inside the coding loop, not in a review meeting that never happens.

Window 2: The commit. The secret hits the repo. Public or private barely matters, because leaked keys are typically abused within the hour. Bots watch GitHub the way seagulls watch a chip van. If your security starts at deployment, you already lost this window.

Window 3: Production, day 30. The app works, the launch tweet did numbers, everyone moved on. Then a dependency CVE drops, the SSL cert quietly expires, and the login route starts eating credential-stuffing traffic at 3 a.m. Nobody is watching, because watching was never set up. This is the window where "it's just a side project" turns into "why is my database on a leak forum."

Traditional AppSec, the annual pentest and the security review meeting, was built for none of these. It assumed code arrived slowly, written by professionals, into environments someone was paid to watch.

The Secure Vibe Coding Checklist: 4 Governance Loops

Forget the enterprise governance stack for a moment. A solo builder or a three-person team will not adopt policy documents. Governance only happens here if it's ambient: installed once, running always, speaking through the tools you already use. In practice that means four loops.

Loop 1: Scan AI-Generated Code at Authorship (MCP in Claude Code, Cursor, Windsurf)

Security feedback has to appear where the code is generated: in the editor, in the terminal, in the AI agent's own context. This is exactly what MCP quietly fixed. Your security tooling can now be a tool inside Claude Code or Cursor, so the agent that writes the vulnerable line can be the agent that's told to fix it, in the same session. The defen.so scanner works this way: the MCP tools plug into your editor and flag risky code as you write it. Scanning that requires leaving the editor is scanning that doesn't happen.

Loop 2: GitHub Repo Scanning and Secret Leak Detection

Secret detection and dependency scanning on every push. Not as a CI moralizer that fails builds three days later, but as an immediate alert. The single highest-ROI security control for a vibe-coded project is knowing within minutes that a key was committed. Everything about window 2 is a race, so enter the race. This is why repo scanning and secret leak detection are built into defen.so from the first command.

Loop 3: Managed WAF and API Rate Limiting for Production

Put a shield in front of production: a managed WAF with sane defaults that blocks injection attempts and bad bots, rate-limits your APIs, and caps the login route against brute force. This is the control that forgives the flaws you didn't catch. The point of a firewall in this era isn't perfection, it's buying you time and cutting the noise while you fix findings at your own pace. And it has to fail open. A security tool that takes your site down has misunderstood its job.

Loop 4: Uptime Monitoring and Multi-Channel Security Alerts

Watch everything that matters: uptime from multiple regions, domain and SSL expiry, new scan findings. And here's the part almost everyone gets wrong: the alert channel matters more than the alert. An email at 3 a.m. protects nobody. The alert has to reach the channel you actually live in. A phone alert that behaves like a call and refuses to be ignored. Slack or Discord for the team. A signed webhook for your ops stack. Severity should choose the volume. This philosophy is the reason the Defen.so Alerts app exists.

That's the whole model. Not a framework with an acronym. Four loops, installed in minutes, running forever.

Vibe Coding Security for Solo Developers and Small Teams

"But I'm just one person."

That's exactly who this is for. The enterprise has a security team to compensate for missing governance. You don't. The solo builder's version of a CISO is automation with good defaults.

And the economics have flipped. Five years ago this stack, SAST plus secret scanning plus a managed WAF plus multi-region monitoring plus on-call alerting, meant six figures of tooling and a hire. Today the whole loop installs from a terminal in under a minute. I know because I built one: defen.so wires the scanner, the WAF, uptime monitoring and the MCP tools with a single npx command, grades your security posture from A to F, and ships every finding with a fix you can paste.

I built it because I lived the gap. Seventeen years of engineering, a decade running dozens of client sites, and the same 3 a.m. lesson everyone learns eventually: the incident you find out about from a customer is the one that costs you the customer.

But tool choice is secondary. Use anything. The loops are the point.

Vibe Coding Security in 2026 and Beyond: Regulation Is Coming

Regulation is coming for this space. Vulnerability reporting duties, insurers carving AI-generated code out of coverage, procurement teams asking where your code came from. Builders who set up ambient governance now will treat those changes as paperwork. The ones who didn't will treat them as an existential crisis, mid-incident.

Vibe coding won. The speed is not going back in the bottle, and it shouldn't. The only question left is whether the safety catches up per project, by default, in minutes. The alternative is a few more years of breach postmortems that all begin with "the app was built in a weekend."

Ship fast. Watch everything. Make the alert loud.

I'm Younes. I build defen.so, a modern security kit for developers and vibe coders: scan your website, apps and GitHub repos for vulnerabilities, block attacks and bad bots, rate-limit your APIs, and monitor uptime, domain and SSL expiry in one platform. The defen.so blog goes deeper on every loop in this guide.

I built a security layer for applications that developers can install in seconds

ONE FANCY APPS — Sun, 26 Jul 2026 14:14:29 +0000

Building Defen.so: a developer-first security layer for modern applications
Most developers know they should add more security to their applications.

A WAF, vulnerability scanning, monitoring, rate limiting, bot protection, file upload checks, security logs...

But in practice, security often becomes a task for "later".

The problem is that later usually means after something goes wrong.
I started building Defen.so with a simple idea:

Security should be part of the application from the beginning, not a separate project.

GitHub:
https://github.com/1fancy/defen.so

Website:
https://defen.so

What is Defen.so?

Defen.so is an application security layer that helps developers protect and monitor their applications without managing complex security infrastructure.

It sits close to your application and provides protection, visibility and security tools from development to production.

The goal is not to replace security teams or enterprise tools.

The goal is to make strong security practices accessible to developers, startups and small teams.

What it currently includes:

Application protection
Managed WAF rules
SQL injection protection
XSS protection
Brute force prevention
API abuse detection
Bot detection
DDoS protection
File upload security
Monitoring
Uptime monitoring
Performance visibility
Real-time security events
Attack logs
Alerts through email, Slack, Telegram and webhooks
Security scanning

Defen.so can scan applications and environments for common issues:

Exposed configuration
Missing security headers
Weak settings
Public files
Common deployment mistakes

There is also a security scan designed around mistakes frequently seen in fast-built applications:

Exposed secrets
Incorrect cloud permissions
Weak authentication configuration
Missing protection layers
Built for developers

Installation is designed to be simple:

npx @defen.so/init

The idea is that adding security should feel closer to installing a package than setting up a large infrastructure project.

Supported ecosystems include:
Node.js, PHP, Python, Go, Ruby, Rust, Java, .NET, Bun, Deno

Security inside your coding workflow

One thing I found interesting while building this is how development workflows are changing.

Many developers now use tools like Claude Code, Cursor, Windsurf and VS Code assistants.

Defen.so includes an MCP server that allows these tools to interact with security information:

Review routes
Check potential vulnerabilities
Analyse security issues
Suggest fixes
Review application behaviour

The goal is to bring security closer to where code is written.

Some technical decisions
Fail open architecture

A security layer should protect your application, not become another availability risk.

If Defen.so is unreachable, the application continues serving traffic.

You lose protection temporarily, not uptime.

Framework-friendly
The same idea should work whether you are building:

A small SaaS
An API
A mobile backend
A customer dashboard
An internal tool
Current status

The project is actively being developed and tested.

Current features include:
SDK packages
Security middleware
Dashboard
Threat monitoring
Scanning workflows
MCP integration
Multiple framework integrations

Repository:
https://github.com/1fancy/defen.so

I would love feedback from developers:

What security tools do you currently use for your applications?
What is the biggest pain point: setup, cost, complexity, or knowing what to fix?

I'm especially interested in feedback from people building SaaS products and APIs.