A young startup in Kampala launches its first app after just three weeks of building with AI coding tools. Customers can sign up, place orders and pay with mobile money. The demo was flawless, early users love it and the founders are already talking to investors.
Then an email arrives from a security researcher. By changing a single number in the app's web address, anyone can view any other customer's name, phone number, delivery address and order history. Nobody wrote that flaw on purpose. The AI simply built a page that fetched an order by its ID, and nobody asked it to check whether the person asking actually owned that order.
This is the reality of vibe coding in 2026. AI tools can produce working software at remarkable speed, but "working" and "secure" are not the same thing. The vulnerabilities that slip into AI-generated code are rarely exotic. They are mostly the classic security mistakes developers have been warned about for decades, now appearing faster and at greater scale than ever.
In an earlier article, we compared vibe coding and traditional coding and explained where each approach fits. This guide goes deeper into security: the most common vulnerabilities in AI-built software, the hidden risks beyond the code itself, and a practical playbook for building fast without leaving the doors open.
At a glance
- AI-generated code is not secure by default. It is optimized to work, not to resist attack.
- Most vulnerabilities are familiar ones: broken access control, injection flaws, exposed secrets, insecure dependencies and misconfigurations.
- Risks also come from outside the code, including AI tools with too much access, security that erodes over many prompts and missing audit trails.
- Traditional security reviews cannot keep up with AI speed. Security has to be built into the workflow where AI code is created.
- The fix is not to stop using AI. It is to treat AI output as untrusted, add automated guardrails and keep experienced humans responsible for what ships.
Why AI-generated code is often insecure
To fix the problem, it helps to understand why it happens.
AI learns from public code, including bad code. Coding models are trained on vast amounts of publicly available software, much of which contains outdated patterns and security mistakes. They reproduce what is common, not necessarily what is safe.
AI optimizes for "it works". When you ask for a feature, the tool's goal is to produce something that runs and does what you described. Security controls that were not mentioned in the prompt are easy to leave out, because the feature still appears to work without them.
AI lacks your context. It does not know which data is sensitive, which users should see what, what regulations apply to you or how attackers target businesses like yours. Unless you tell it, it guesses.
AI sounds confident. Generated code often looks clean and comes with a convincing explanation. That polish makes it easy for people, especially non-technical founders, to trust it more than they should.
Eight common vulnerabilities in vibe-coded apps
1. Broken access control
This is the flaw in our opening story, and one of the most common and damaging problems in AI-built apps. The application checks that a user is logged in, but not whether they are allowed to see or change a specific record. Attackers simply change an ID in a request to access other people's accounts, orders or files.
The fix: enforce authorization on every request, on the server, for every resource. Check ownership and roles explicitly, and test what happens when one user tries to access another user's data.
2. Unprotected APIs and admin functions
AI tools often create API endpoints and admin pages quickly, but forget to protect them. Internal dashboards end up publicly reachable, and back-end APIs accept requests from anyone who finds them.
The fix: require authentication on every endpoint by default, restrict admin functions to specific roles and networks, and keep an inventory of every API your application exposes.
3. Injection flaws
SQL injection happens when user input is inserted directly into a database query, allowing attackers to read, change or delete data. Similar risks exist with operating system commands and dangerous functions that execute text as code, which can lead to remote code execution, where an attacker runs their own code on your server.
The fix: always use parameterized queries or a trusted ORM, never build queries by joining strings, avoid functions that execute arbitrary input, and validate all input on the server.
4. Cross-site scripting (XSS)
If an application displays user-supplied content without properly encoding it, attackers can inject scripts that run in other users' browsers, stealing sessions or performing actions on their behalf.
The fix: encode all output, rely on frameworks' built-in protections rather than bypassing them, and use a content security policy.
5. Exposed secrets
AI-generated code frequently places API keys, database passwords and payment credentials directly in the source code, configuration files or front-end bundles, where they can leak through public repositories or the browser. Sensitive data also ends up in logs.
The fix: store secrets in environment variables or a secrets manager, never in code. Use automated secret scanning on every commit, rotate any key that has ever been exposed and keep personal data out of logs.
6. Insecure payment and webhook handling
This one matters enormously in African markets. Mobile money and card payment providers notify your application through callbacks or webhooks. AI-generated code often accepts these notifications without verifying that they genuinely came from the provider, or marks an order as paid without confirming the transaction status. Attackers can then fake payment confirmations.
The fix: verify the signature or source of every payment callback, confirm transaction status directly with the provider before releasing goods or services, and make payment processing idempotent so duplicate notifications cannot trigger duplicate actions. Our finance and payments team builds these flows with security at the core.
7. Risky dependencies and fake packages
AI tools pull in third-party libraries freely. Some are outdated with known vulnerabilities, some are unnecessary, and some do not exist at all. Attackers have started publishing malicious packages under names that AI tools commonly invent, a technique sometimes called "slopsquatting", so a hallucinated dependency can install malware directly into your project.
The fix: review every new dependency, verify that it is the genuine, maintained package, lock versions, and run automated dependency scanning to catch known vulnerabilities.
8. Dangerous misconfigurations
Many AI-built apps are secure in their code but exposed by their setup: databases open to the internet, cloud storage buckets set to public, debug mode left on in production, overly permissive cross-origin settings or default passwords never changed.
The fix: review infrastructure configuration as carefully as code, use infrastructure as code with security checks, and harden every environment before launch. Our cloud and infrastructure team designs environments that are secure by default.
Hidden risks beyond the code
Some of the most serious risks do not appear in any single line of code.
Security erodes over iterations. Each new prompt adds or changes code. A feature that was secure on day one can become vulnerable after ten rounds of "just add this" and "fix that", especially when new endpoints are added without the original protections.
AI tools themselves become a target. AI coding assistants and agents may have access to your files, terminal, databases or cloud accounts. Malicious instructions hidden in a web page, a document or a dependency, known as prompt injection, can trick them into running harmful commands or leaking data. The more access you give them, the greater the risk.
Reduced visibility and auditability. When large amounts of code are generated quickly, nobody may fully understand how the system works. If a breach happens, tracing what went wrong becomes slow and difficult.
Compliance blind spots. AI does not know that you are subject to Uganda's Data Protection and Privacy Act, Bank of Uganda requirements or health data obligations. It can easily produce code that collects, stores or shares personal data in ways that create legal exposure.
Why traditional security processes fall behind
In many organizations, security reviews happen late: a scan before release, or a penetration test once a year. That model struggles with AI-assisted development.
AI can generate hundreds of lines of code in minutes, far faster than any human can review. Security scanners produce long lists of findings that nobody has time to work through. And when security tools sit outside the developer's workflow, feedback arrives days after the vulnerable code was written.
The answer is to move security to where the code is created: into the prompts, the development environment, the pull requests and the deployment pipeline.
A practical playbook for securing AI-generated code
Treat AI output as untrusted. Review AI-generated code with the same suspicion you would apply to code from an unknown contributor. Nothing goes to production without review.
Put security requirements in your prompts. Tell the AI what "done" means, including authorization rules, input validation, error handling and what data must never be exposed. Teams can maintain a standard block of security rules that is added to every prompt.
Make the AI ask, not guess. For anything touching authentication, permissions, payments or personal data, instruct the AI to stop and ask questions instead of making assumptions.
Ask for a security review before accepting code. Have the AI analyze its own output for vulnerabilities as a separate step. It will not catch everything, but it catches more than you might expect.
Automate guardrails in the pipeline. Run static code analysis, secret scanning and dependency scanning automatically on every pull request, so unsafe code is flagged before it is merged. This is the heart of a modern DevOps and DevSecOps practice.
Test how the application behaves. Static scans miss many problems. Test real behaviour: try to access another user's data, send malformed input, call admin endpoints without permission and replay payment callbacks. For important systems, commission an independent penetration test before launch.
Limit what AI tools can access. Give coding assistants and agents the minimum access they need. Use sandboxed environments, read-only database accounts and separate credentials, and never connect them to production systems without strict controls.
Keep humans accountable. Every system that matters needs experienced engineers who understand it, approve what ships and are responsible when something goes wrong.
A pre-launch checklist for founders and product owners
If your product was built with AI tools, ask these questions before real users and real money arrive:
- Can one user ever see or change another user's data?
- Is every API and admin page protected by proper authentication and role checks?
- Are any passwords, API keys or payment credentials stored in the code or exposed in the browser?
- Are payment confirmations verified directly with the provider before orders are fulfilled?
- Are databases, storage and admin tools closed to the public internet?
- Do you know every third-party library your app uses, and are they up to date?
- Is personal data collected, stored and shared in line with Uganda's Data Protection and Privacy Act?
- Has someone with security expertise reviewed the application?
If any answer is "no" or "I'm not sure", fix it before you scale.
NASDAN as your partner on the AI journey
AI coding tools are here to stay, and they are a genuine advantage for teams that use them well. The organizations that win will not be the ones that avoid AI, but the ones that combine its speed with disciplined engineering and strong security.
At NASDAN, we use AI-assisted development every day, and we hold AI-generated code to the same standards as everything our engineers write. We help startups and established organizations do the same:
- Security audits of AI-built applications. Our cybersecurity specialists review your code, architecture, dependencies and configuration, then prioritize and fix the most critical risks.
- From prototype to production. Our custom software engineers strengthen, refactor or rebuild vibe-coded MVPs into secure, scalable products.
- Secure development pipelines. We embed code scanning, secret detection, dependency checks and automated testing into your workflow through our DevOps practice.
- Secure cloud environments. We design and harden infrastructure on AWS, Google Cloud and Azure through our cloud and infrastructure services.
- Safe payment integrations. We build verified, reliable mobile money and card payment flows for fintech and e-commerce platforms.
- Responsible AI adoption. We help teams set clear rules for using AI and machine learning tools, including what they can access and what always needs human approval.
- Ongoing protection. Our managed IT services keep your systems monitored, patched and secure after launch.
Whether you are a startup preparing to launch your first AI-built product or an enterprise rolling out AI coding tools across your teams, we follow our proven five-phase delivery process to make speed and security work together. You can also read more about our approach in our article on rethinking cybersecurity in the age of digital transformation.
Built something with AI and want to know if it's safe to launch? Start a project or talk to our team about a security review.
Frequently asked questions
Is AI-generated code secure? Not by default. AI tools focus on producing code that works, and frequently leave out security controls such as authorization checks, input validation and secure secrets handling unless specifically asked. All AI-generated code should be reviewed and tested before it reaches production.
What is the most common vulnerability in vibe-coded apps? Broken access control is among the most common and damaging. The app checks that a user is logged in, but not whether they are allowed to access a specific record, so users can view or change other people's data by altering an ID.
What is slopsquatting? It is an attack where criminals publish malicious software packages under names that AI tools tend to invent. If a developer installs a dependency suggested by AI without checking it, they may install malware instead of a genuine library.
Can AI tools find security vulnerabilities in code? They can help, and asking an AI to review code for security issues is a useful step. But AI reviews miss many problems, especially those involving business logic and context, so human review and automated security tools are still essential.
Should businesses stop using AI coding tools? No. AI tools offer real productivity gains. The key is to use them inside a disciplined process with clear security requirements, automated guardrails, limited tool access and experienced humans who remain accountable for what ships.
How can I check whether my AI-built app is secure? Start with the pre-launch checklist in this article, run automated code and dependency scans, and for any app handling money or personal data, commission a professional security review or penetration test before scaling.