AI-assisted development tools have made it faster and cheaper to build web applications. Platforms like Vercel and frameworks like Next.js have lowered the barrier further. A small business can now ship a customer portal, internal tool, or booking system in weeks, often with minimal developer involvement.
That's genuinely useful. What it doesn't do is make the application secure.
We're seeing this pattern regularly in Australian businesses. An application is built quickly, often with significant AI assistance, and it functions exactly as intended. The security controls haven't received the same attention as the features. The application goes live, and the problems surface later.
AI development tools have changed how applications get built
Tools like GitHub Copilot and Cursor are good at producing working code. They understand common frameworks, generate boilerplate efficiently, and can turn a plain English requirement into a functional implementation. For most development tasks, they save real time.
Security is a different problem. It requires understanding not just what the code does, but how an attacker might interact with it, what assumptions the developer made, and whether those assumptions hold under adversarial conditions. That kind of reasoning isn't where AI coding tools are strongest, and it rarely comes up in a standard development workflow unless someone is actively looking for it.
The result is an application that works correctly, passes informal testing, and still has real security weaknesses in it.
The security gaps that appear most often
The vulnerabilities we see in AI-assisted applications aren't unusual. They're the same class of issues found in applications built by under-resourced teams without security input.
- API keys, tokens, and environment variables committed to repositories or embedded in client-side code.
- Weak authentication, including insufficient session management and missing account lockout controls.
- APIs with no rate limiting, making them straightforward to enumerate or abuse.
- Third-party packages with unreviewed vulnerabilities.
- Excessive permissions granted to service accounts or authenticated users.
- Logging that records too little to be useful when something goes wrong.
They appear consistently at the top of web application lists because they're easy to miss and relatively easy to exploit.
Hosting on Vercel or Next.js doesn't make your application secure
Vercel is a reliable hosting platform. Next.js is a well-maintained framework with sensible defaults in certain areas. Neither fact means an application deployed on them is secure.
These platforms handle infrastructure and provide a reasonable baseline for how traffic is managed. They don't review your code, validate your authentication logic, or check whether your API keys are exposed. That's on whoever built and deployed the application.
A Next.js application can have secrets committed to a public repository. A Vercel deployment can serve an application with broken access controls. The platform doesn't prevent either of those things.
Cloudflare as a security layer — useful, but not a substitute
Cloudflare sits in front of your application and handles a class of threats at the network and edge layer. For AI-built applications that go public quickly without a proper security review, it's worth understanding what each product actually does and where it stops.
Turnstile
Cloudflare Turnstile is a CAPTCHA alternative that distinguishes human users from bots. It protects login pages, contact forms, and any public input from automated abuse and spam submissions without adding friction for real users. Easy to add, does what it says. It operates at the edge before requests reach your application, so anything that gets past it, or that exploits a flaw inside the application itself, is outside its scope.
Web Application Firewall
The Cloudflare WAF inspects HTTP traffic and blocks requests that match known attack patterns, things like SQL injection attempts, cross-site scripting payloads, and common exploit signatures. It's a useful layer for catching opportunistic attacks and known CVEs targeting popular frameworks. It won't catch logic flaws or vulnerabilities specific to your application's architecture, and it won't protect you from an attacker who takes the time to understand how your application works before probing it.
DDoS protection
Cloudflare's DDoS protection absorbs volumetric attacks before they reach your origin server. For most publicly accessible applications, this is worth having. It keeps the application available under automated flood conditions. Availability is not the same as security, but losing availability to a flood attack while real vulnerabilities go unaddressed is a bad combination.
Zero Trust access
Cloudflare Access lets you put internal tools and admin panels behind an identity-aware proxy, requiring authentication before a request reaches the application at all. For internal applications that would otherwise be exposed to the internet, this is one of the more practical controls available. It reduces the attack surface significantly, though it doesn't replace securing the application itself.
Taken together, these controls reduce exposure to a wide class of automated and opportunistic threats. What they don't address is the code running behind them. An application with broken authentication, exposed secrets, or insecure API integrations remains vulnerable to a targeted attacker regardless of what sits in front of it.
What responsible application security looks like
Security should be part of the development process, not something bolted on after go-live.
In practice that means:
- Secrets and environment variables managed properly, never embedded in code or committed to a repository.
- on developer accounts and the platforms they deploy to.
- Rate limiting on APIs, login pages, and forms.
- A code review before deployment that actually covers security, not just functionality.
- Dependency scanning.
- Logging and monitoring that gives you visibility when something behaves unexpectedly.
None of this is expensive. It does require someone to actually think about it before the application ships.
Why penetration testing still matters
Automated scanning can catch some things. It should be part of any development workflow. What it doesn't replace is a human-led penetration test.
A penetration test looks at the application the way an attacker would. It examines how components interact, tests assumptions about authentication and access control, and finds things automated tools routinely miss: chained issues, logic flaws, problems specific to how the application was built. Those findings don't come from a scanner.
For applications handling customer data, financial records, or anything sensitive, testing before go-live means you know your controls are working rather than assuming they are. Problems found before production are also significantly cheaper to fix than problems found afterwards, by a customer or a regulator.
If the application is already deployed, testing the live environment still gives you a useful picture of actual exposure.
Frequently asked questions
Is a Next.js application secure by default?
It ships with some security defaults, including HTTP headers and server-side rendering protections. Those are a starting point, not a security posture. Actual security depends on how the application is designed, which libraries it uses, how secrets are managed, and whether the authentication logic behaves correctly under pressure.
What is Cloudflare Turnstile and what does it protect against?
A CAPTCHA alternative that distinguishes human users from bots. Useful for protecting forms and login pages from spam and automated abuse. It has no visibility into vulnerabilities inside the application itself.
When should a web application have a penetration test?
Before it goes live, particularly if it handles sensitive data or is externally accessible. If it's already in production, testing against the live environment is still worthwhile. Significant changes to functionality or infrastructure are also a reasonable trigger.
Do AI-built applications need the same security controls as traditionally developed ones?
Yes. The risks come from what the application does and how it's built, not which tools were used to build it. AI-assisted development adds some specific things to watch, particularly around code review and secrets handling, but the underlying controls are the same.
Talk to us about application security
If you'd like an independent security review of an existing application, or are planning a new deployment, we can help you work out what's worth examining and what a structured assessment involves. Contact IronSights to discuss the available options.
For ongoing protection beyond the application layer, Fortify provides continuous managed security monitoring for Australian businesses.
