Indian Startups Shipping Vibe-Coded Apps: A Risk Checklist for 2027

Vibe coding - using AI tools like Lovable, Bolt, Cursor, or v0 to generate a working app from a prompt - has made it possible for Indian founders to ship a product in days. The risk is not the speed. The risk is that the tools generate code which looks complete, but which contains security gaps, handles personal data without the controls the law now requires, and does not reflect the compliance landscape that Indian founders specifically face. This checklist covers what to check before your app has real users - through a security lens, and with notes on CERT-In and DPDP obligations. Nothing here is legal advice. For specific compliance obligations, consult a qualified legal adviser.

Why the Indian context adds specific risks

CERT-In's 2022 directions require any service provider, intermediary, data centre, body corporate or Government organisation to report the incident types listed in their Annexure I within six hours of noticing them. The list includes data breaches, data leaks and unauthorised access to systems. A registered startup is normally a body corporate, so assume the directions apply to you and confirm with a legal adviser. The six-hour clock starts when you notice the incident or are told about it.

The Digital Personal Data Protection Act 2023 and the DPDP Rules, gazetted on 13 November 2025 apply in stages: the Consent Manager rule (Rule 4) one year after the gazette date, and most other rules, including breach notification, eighteen months after it, so around 13 May 2027 (Rule 1 of the gazette text). If your app collects personal data - and almost all apps do (user email, phone, location, purchase history) - you are a Data Fiduciary under the Act, with obligations around consent, data minimisation, and breach notification. Build to the requirements now, because retrofitting compliance into an existing app is harder than building for it from the start.

The security gaps vibe-coded apps consistently carry

These are the patterns worth checking in every AI-built app. They are not hypothetical: UpGuard found 16,326 databases exposing readable tables across roughly 300,000 candidate domains showing Supabase usage.

Supabase tables with no Row-Level Security (RLS) policies: when AI tools create Supabase tables, RLS is often disabled. Without RLS, the anon key - which Supabase designs to be exposed in frontend code - can read every row in every unprotected table
Service role key in the frontend bundle: the service role (secret) key bypasses every RLS policy. If it ends up in a .env file that gets committed to a public repository, or in a client-side config file, every row in your database is readable by anyone who finds the key
No input validation on API endpoints: AI-generated API routes often lack input validation. Without validation, endpoints can be sent malformed data, excessively large payloads, or injection attempts
Hardcoded API keys in source files: AI tools sometimes suggest storing third-party API keys (for email, SMS, payments, or LLM services) directly in source files during prototyping. These often remain there at launch
No rate limiting on public endpoints: any endpoint reachable without authentication can be called thousands of times a minute. Without rate limiting, this causes bill spikes (if the endpoint calls a paid API), denial of service for other users, and data enumeration

The AI-built app security checklist covers all of these in more depth, with specific checks per gap. If your app is on Supabase, also check whether your RLS policies are working correctly - it is possible to have RLS enabled but still expose data through policy mistakes.

DPDP compliance checklist for apps collecting personal data

Note: this is a technical orientation, not legal advice. Engage a qualified adviser before making compliance representations to users or investors.

Consent before collection: do you obtain explicit, informed consent from users before collecting their personal data? The Act requires consent to be free, specific, informed, unconditional and unambiguous, with a clear affirmative action (section 6). Pre-ticked boxes and bundled consent do not meet this standard
Purpose limitation: are you collecting only the personal data your app needs for its stated purpose? Collecting extra data 'in case it is useful later' creates both compliance risk and security exposure
Data minimisation in practice: check your database schema. Are you storing data you no longer use? Stale user records, historical logs with personal identifiers, or third-party data copied into your database that you do not need?
Breach notification readiness: do you have a documented process for identifying a data breach, assessing its scope, and notifying the Data Protection Board and affected users, as Rule 7 will require? The process does not need to be complex - it needs to exist before you need it
Data Principal rights: the Act (sections 11 and 12) gives individuals rights to obtain information about their data and to seek its correction and erasure. Does your app provide a way for users to make these requests?
Third-party data processors: if you share personal data with third parties (email service providers, analytics platforms, payment processors), do your contracts with them reflect appropriate data processing obligations?

CERT-In incident readiness checklist

The six-hour reporting window for CERT-In is tighter than most startups expect. Being ready to report means having the information you need assembled before an incident happens, not during one.

Do you know how to reach CERT-In? The Directions list incident@cert-in.org.in and a phone line for reporting. Save both where your whole team can find them
Do you log access to your production systems? CERT-In may ask for logs as part of a report, and the Directions expect ICT system logs to be kept for a rolling 180 days. If you have no logs, say so - but the absence of logs limits what you can report
Do you have a named person responsible for security incidents? In a small team, this is usually the technical co-founder. The person needs to know their role before something happens
Do you know your IP ranges and domain names? CERT-In incident reports require identifying your systems. Having this documented saves time under pressure
Have you read CERT-In advisory CIAD-2026-0049 (15 October 2026)? Its title covers unauthorised access by AI agents under evaluation and misuse of open-source agentic AI tools targeting Indian ICT assets, and it recommends auditing for exposed credentials, keeping privileged keys out of client-side code and testing what anonymous users can read and write

What makes Indian-built apps a specific target

Indian startup apps are not targeted differently from apps anywhere else. But the ecosystem has characteristics that increase exposure. The rapid adoption of AI coding tools among Indian founders means a large number of apps have shipped with similar security patterns - the same tool creates the same gaps. An attacker who learns what Supabase tables look like without RLS, or what a Lovable-generated API endpoint structure looks like, can probe many apps with the same technique.

This is not a reason not to use AI coding tools. It is a reason to audit the output before you launch with real users.

The cost of finding this late

A security review before launch is a defined cost - it takes a fixed amount of time against a stable codebase. A security review after a breach involves the same technical work plus: incident response, customer communications, potential CERT-In reporting, legal advice, and the reputational cost of the disclosure. Founders who ask 'do we really need to check this before we launch?' are comparing the cost of review against zero - but the comparison should be against the cost of finding the gap after launch.

The CERT-In AI agents advisory checklist covers the specific controls CERT-In recommends for teams using AI in their development and deployment processes. The DPDP breach response guide walks through the notification process if you have already had an exposure. If you want to check your app's security posture before your next launch, the free app health check scans for the most common gaps automatically, and a technical review gives you a complete picture.

Common questions

What do CERT-In rules require if my app has a data breach?

CERT-In's 2022 directions require service providers, intermediaries, body corporates and others to report the incident types in Annexure I, including data breaches and leaks, within six hours of noticing them. A registered startup is normally a body corporate, so confirm with a legal adviser. This is not legal advice.

What security gaps do vibe-coded apps usually have?

Common ones are Supabase tables with no row-level security, a service role key in the frontend bundle, no input validation on API endpoints, hardcoded API keys in source files, and no rate limiting on public endpoints. UpGuard found 16,326 databases exposing readable tables across roughly 300,000 candidate domains.

Should I get my vibe-coded app checked before launch?

A security review before launch is a defined cost against a stable codebase, while one after a breach adds incident response, customer communications and legal advice. The free app health check scans for the most common gaps, and a technical review gives you a complete picture.