Is It Safe?

“Is X safe?” is the wrong question by itself — every modern dev platform is “safe” at the infrastructure layer. The question that actually matters is: what does this tool let you ship that is broken? Each review below is structured around that gap. The platform passes its own SOC 2; the apps built on top of it are where the incidents happen.

We group the reviews into four buckets because the failure modes group cleanly that way. AI IDEs fail through code that the model wrote and the human glanced at. Hosting fails through env-var scope and OAuth-app sprawl. Databases fail through missing or wrong row-level security. No-code fails through over-permissive integrations and exposed admin URLs. Read the bucket your stack lives in first.

AI Coding Platforms

The shared failure pattern: generated code passes the developer’s eye because the intentional diff looks correct. The dangerous changes are the ones the human didn’t notice — a CSRF check removed “to make the test pass”, a CRUD endpoint without an owner check, an auth middleware that returns next() on the negative path. Every review in this bucket assumes the IDE is fine and asks what it lets through.

Databases & Backends

The shared failure pattern: the database is exposed directly to the browser via a public anon key (Supabase, Firebase, PlanetScale-with-Hyperdrive, etc.), and the only thing standing between an attacker and the data is a row-level-security policy or a Firestore rule that the developer may or may not have written. Read the platform you use, then verify policies with a real test — not by reading them.

Hosting

The shared failure pattern: the platform is hard, but the surface around it — env-var scoping, preview-deployment exposure, third-party OAuth apps with dashboard reads, edge middleware that silently regresses — is where every recent incident has actually happened. Read the host you use, then audit your Integrations list and your env-var Sensitive flags.

No-Code / Low-Code

The shared failure pattern: workflows and plugins run with the credentials of whoever installed them, admin URLs are guessable, and the “publish” button skips the review step that a code-based stack would force. Read the tool, then check who has admin access and what plugins are installed.

Where to start

If your stack spans more than one bucket — most do — the practical order to scan is:

Database first. A missing RLS policy or open Firestore rule is the highest-blast-radius bug you can ship. Scan tables and rules before anything else.
AI-generated code second. If you’re using Cursor, Lovable, Claude Code or similar, every PR has a non-trivial chance of a silent regression. Diff security-sensitive files against main on every merge.
Hosting third. Audit env-var scopes, preview-deployment protection, and the OAuth-app list quarterly. The Context.ai April 2026 incident showed how a single over-scoped integration can sweep up secrets across hundreds of accounts.
No-code last. Lower volume of incidents but harder to audit because the platform owns the runtime. Focus on the admin-access list and installed plugins.

Common questions across tools

Is the platform safe? Almost always yes. SOC 2 Type II, encrypted secrets, managed patching. Not the bug surface.
Are apps built on the platform safe by default? Almost always no. The defaults optimize for shipping fast, not for production hardening.
Where do real incidents come from? Misconfigured RLS, leaked service-role keys, over-scoped OAuth apps, missing auth on generated CRUD endpoints, and preview deployments that ship to public URLs with production credentials.
What should I scan before launch? Database rules, frontend bundle for leaked keys, every CRUD endpoint with a second test user, security headers, and the OAuth-integration list on your hosting account.

A safety review is a starting point. The only safety check that matters is the one you run on the actual deployed app — which is what VibeEval does.