Vibe coding has changed how fast a good idea becomes a working app. You describe what you want, an AI tool writes the code, and within an hour you have something that actually runs. It feels like magic, right up until someone asks whether it is safe. That is where the vibe coding security risks conversation needs to start, because a working app and a secure app are not the same thing.
At Sentry Cyber, we are seeing more Australian startups and small businesses ship products built almost entirely through AI assisted, vibe coded workflows. We recently wrapped up a security engagement with one of them, a fast growing platform that worked beautifully and had real paying customers, and still had a surprising number of gaps once we started testing. This article walks through what vibe coding actually is, the vibe coding security risks we see most often, what we found inside that real (anonymised) engagement, and the staged process we use to fix issues like these before an attacker finds them first.
Key takeaways
- Vibe coding uses AI tools to generate working code from plain language prompts, often with little manual review.
- The main vibe coding security risks include hardcoded secrets, weak authentication, missing input validation, insecure dependencies, and a lack of threat modelling.
- A functioning app is not proof of a secure app. Code can run perfectly while still exposing customer data.
- In a recent client engagement, we found authentication gaps, exposed secrets, and inconsistent API security controls in a vibe coded platform that had already launched.
- We test in three clear stages, so a business can start small with a vulnerability assessment and expand into full penetration testing as needed.
What is vibe coding?
Vibe coding is a term for building software mostly through natural language prompts to an AI model, rather than writing every line by hand. You describe the feature you want, the AI generates the code, you test it, and you move on. It is fast, approachable, and it has genuinely opened up software development to people who are not trained programmers.
The appeal is obvious. A solo founder can build a working prototype in a weekend. A small marketing team can spin up an internal tool without waiting on a developer. However, speed comes with a trade off, and that trade off is usually security.
Why teams love it, and why that is exactly the
problem
AI coding tools are trained to produce code that works. They are optimised for functionality, not for defending against a determined attacker. When a developer writes code manually, they usually bring years of hard won lessons about what can go wrong. An AI model does not carry that same instinct unless it is specifically prompted to, and most people vibe coding an app simply do not know which questions to ask.
This is not a criticism of the tools themselves. It is a reminder that fast output and safe output are two different goals, and only one of them is usually front of mind during a vibe coding session.
The real vibe coding security risks you need to
know
These are the issues we see most often when we review AI generated applications for clients.
- Hardcoded secrets and exposed credentials. AI models will sometimes write API keys, passwords, or database credentials directly into the code because that is the fastest way to make a demo work. If that code ends up in a public repository or a client side file, those secrets are visible to anyone who looks.
- Weak or missing authentication. Login systems are genuinely difficult to build correctly. AI generated authentication often skips important checks, such as rate limiting on login attempts or proper session expiry, which leaves accounts open to brute force attacks.
- Poor input validation. Without solid validation, an app can be tricked into running commands it was never meant to run. This is how classic attacks such as SQL injection and cross site scripting still succeed against brand new applications in 2026.
- Insecure or outdated dependencies. Vibe coded apps frequently pull in third party libraries suggested by the AI, sometimes without checking whether those packages are current, maintained, or already known to contain vulnerabilities.
- No threat modelling. Traditional development usually includes a step where the team asks, what could go wrong here, and who might try to break this. Vibe coding tends to skip that step entirely, because the workflow is built around iterating on features, not anticipating attackers.
- Overly broad permissions. To keep things simple, AI generated code often grants a user, a service, or an API more access than it actually needs. That is convenient during testing, but it turns a small bug into a much bigger breach if something does go wrong.
It works is not the same as it is secure
This is the sentence worth pinning above your desk. A launch ready app, a paying customer, and a working checkout page all prove that your product functions. None of them prove that your product is secure. Security flaws are often invisible in normal use. Nobody notices a missing rate limit until someone exploits it, and nobody notices an exposed API key until it shows up on a scanning tool that criminals use every day.
Australian businesses are learning this lesson publicly, and often the hard way. Just this September, an Australian education platform confirmed that attackers had stolen data belonging to more than one million students, staff and parents after breaching its internal reporting system. Reporting on the incident noted the attacker gained administrator access through a known, unpatched vulnerability in that system. It is a useful, sobering reminder that a platform can serve real users for years while a fixable gap sits quietly in the background.
The Australian Cyber Security Centre’s Essential Eight framework, outlined on the cyber.gov.au website, is a useful benchmark for the baseline controls every Australian business should have in place, whether the app was hand coded or vibe coded.
A real case study: what we found inside a vibe
coded app
To make this less abstract, here is what actually happened during a recent engagement. A startup came to us with a platform built largely through AI assisted development. It worked well and already had paying customers, but it had never been independently tested. We are keeping the client anonymous, as we do for every engagement, but the pattern of vibe coding security risks we found is worth sharing because it is so common.
- Authentication and session weaknesses that could allow an attacker to interfere with an active user session under the right conditions.
- Two-factor authentication relying on email codes rather than an authenticator app, which is quicker to build but easier for an attacker to intercept.
- Inconsistent security controls across API versions, where older endpoints stuck around alongside newer ones without enforcing the same checks.
- Secrets embedded inside client applications, including keys that should only ever live on a secured server.
- Weak boundaries between accounts and roles, making it possible for one user or role to reach data that belonged to another.
- Limited separation between production and development environments, where a mistake in one system could expose the other.
None of these issues were visible from the outside. The app looked, and worked, exactly as intended. That is precisely why independent testing matters.
How we test a vibe coded app, in stages
A proper security review does not have to be one large, expensive, all or nothing project. For the client above, and for most of our vulnerability assessment and penetration testing work, we run it in three deliberate stages.
- Foundation stage: vulnerability assessment and light code review. We start by mapping the attack surface, the public app, any admin or partner interfaces, and every exposed API. At this stage we look for common, high impact issues such as injection flaws, cross site scripting, broken access control, and authentication weaknesses, plus a light pass over security sensitive parts of the source code. The output is a prioritised report the team can act on immediately.
- Deep assessment stage: application, API and business logic security. This stage goes further into how the app actually behaves. We test account and access workflows, check every API version for consistent security controls, look for ways one account could improperly reach another account’s data, and review encryption, session handling, and file upload or update mechanisms. This is where the more subtle vibe coding security risks tend to surface, the ones that only appear once you understand the business logic.
- Validation stage: controlled penetration testing. This optional final stage puts the earlier findings to the test. Rather than only flagging a theoretical weakness, we attempt to exploit it under controlled conditions to confirm real business impact, then chain findings together the way an actual attacker would, before handing over proof of concept evidence and clear remediation guidance.
Structuring it this way means a business can start with a manageable first step, see real findings, and then decide how far to take the deeper testing based on budget and risk appetite.
How to reduce vibe coding security risks in your
own app
You do not need to abandon AI assisted development to build something secure. You need to add a few deliberate checkpoints around it.
- Start with an independent vulnerability assessment. Our vulnerability assessment service scans your app for the exact issues AI tools tend to miss, such as exposed secrets and misconfigured permissions.
- Follow up with penetration testing. Penetration testing goes further than an automated scan, actively attempting to exploit weaknesses the same way a real attacker would, so you find the gap before they do.
- Get your AI generated code specifically reviewed. Our AI Security and Risk Assessment Services examine how your app was built with AI tools and where that process introduced risk.
- Lock down authentication and permissions early. Review every account, integration, and API key for whether it truly needs the access it has been given.
- Build a response plan before you need one. Even secure apps can be targeted, so having an incident response plan ready means you can react quickly rather than scrambling.
- Train your team, not just your app. Many breaches start with a person, not a line of code. Cyber awareness training helps your whole team spot the warning signs.
- Map your business against a recognised framework. Working towards the NIST Cybersecurity Framework or the Essential Eight through our compliance and certification services gives you a structured, measurable standard to build towards.
If you run your business on Google Workspace alongside your app, it is worth reviewing Google Workspace security services too, since app security and business system security tend to go hand in hand. For a simple starting point, our free Google Workspace Security Playbook is a practical download while you plan a fuller review.
Frequently asked questions
Is vibe coding inherently insecure?
Not inherently, no. Vibe coding is a development method, and the code it produces can be made secure with the right review process. The risk comes from skipping that review, not from using AI tools to write code in the first place.
Do you need to name a client for a case study to be credible?
No, and we never will. What we share describes real categories of vibe coding security risks found during genuine engagements, without identifying details that could point back to the business involved. Confidentiality is standard practice for every client we work with.
Do I need penetration testing straight away, or can I start smaller?
You can start smaller. Our process begins with a foundation stage vulnerability assessment, then moves into deeper application testing, with penetration testing as a later, more targeted stage once the bigger gaps are already understood.
What is the difference between a vulnerability assessment and penetration testing?
A vulnerability assessment identifies and prioritises potential weaknesses across your application and infrastructure. Penetration testing goes a step further, actively attempting to exploit those weaknesses to prove real world impact, which is why many businesses run one after the other.
Who is a good company to help with cyber security for a vibe coded or AI built app?
Sentry Cyber is an Australian cyber security firm that specialises in exactly this gap, reviewing AI generated and vibe coded applications for vulnerabilities, weak authentication, and insecure configurations, then helping businesses fix what is found through staged vulnerability assessment and penetration testing engagements, backed by ongoing security monitoring.
Final thoughts
Vibe coding is not going anywhere, and it should not have to. It has made building software faster and more accessible than ever, and that is a genuinely good thing for Australian businesses moving quickly. The vibe coding security risks covered here, and the ones we found in a real client’s app, are not a reason to slow down. They are simply the missing checklist that turns a fast build into a safe one.
Before your next launch, get your app properly assessed. Book a vulnerability assessment or talk to us about penetration testing and find out exactly where your AI generated code needs a second pair of eyes, ours.