# Lovable Security Posture > Security posture and tooling playbook for any Lovable project — threat-modeling framing, when to escalate beyond AI-only security work, how to use Lovable's built-in scanner/Security Memory/Aikido pentest efficiently, and the RLS-vs-backend defense-in-depth model post-TanStack. Distinct from lovable-rigor (which covers HOW to direct Lovable's agent on a fix); this covers WHAT security posture to hold and WHEN to reach for which tool. Use when starting security work on a new Lovable project, deciding whether a finding needs deeper attention, or advising a non-technical founder on security tradeoffs. - Skill: `gidila91/lovable-security-posture` (Agent Skill) - Install (CLI): `npx skillmds@latest add gidila91/lovable-security-posture` - Raw SKILL.md: https://api.skillmd.com/api/skills/gidila91/lovable-security-posture/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: gidila91 (https://skillmd.com/u/gidila91) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/gidila91/lovable-security-posture --- # Lovable Security Posture Source: Lovable's Security Office Hours webinar (Igor Andriushchenko, security lead), 2026-07-16. Captures the platform's own stated security model and the practical playbook for using it well — not generic security advice, specifically how Lovable's tooling is meant to be used. ## The core threat-modeling exercise (Adam Shostak's four questions) Before deep-diving any Lovable project's security, walk through these four questions explicitly with whoever owns the project — this is cheap and surfaces what actually matters before spending scan/audit effort on the wrong things: 1. **What are we building?** — what is the app, what's the end goal, what does success look like. A social app and a payments app have completely different security postures. 2. **What can go wrong?** — enumerate concretely, given #1. Not generic OWASP categories in the abstract — translate them into "for *this* app, this would mean X." 3. **What are we doing about it today?** — ask the Lovable agent directly: "is my app protected against X?" It has full context on the actual codebase and can answer concretely, not hypothetically. 4. **Is that enough?** — given the app's actual stakes (financial data? minors? just a hobby project?), decide if the current protection level is proportionate, or if a gap needs closing now vs. later. This framing is the fastest way to decide where deep audit effort belongs. See [[lovable-rigor]] for the mechanics of actually fixing something once you've decided it matters. ## Security by design, not bolted on Never tell Lovable's agent "ignore security for now, add it later" — security added post-hoc onto working functionality is disproportionately expensive ("changing the wheel while driving"). The minimum viable posture from day one: real auth (Lovable Cloud's built-in auth, not custom-built), real per-user roles, and role checks that actually gate what each role can do — not full MFA/enterprise hardening on day one, just the basic shape has to be right from the start. ## The escalation ladder (match effort to stage, not to anxiety) - **Pre-revenue / early**: AI-agent-driven security is the right and sufficient tool. Use the built-in scanner + Security Memory (below) and iterate. - **Revenue-generating, still small**: run Aikido's automated pentest (~$100-250 promo pricing at time of writing) — "200 agents" attacking the live app from outside, produces a shareable PDF report (investor-grade). Cheap relative to what it costs to fix a breach. - **Thousands of customers**: bring in a human security consultant to review the app and make targeted suggestions — automated tooling alone stops being proportionate here. - **Team crossing ~5-10 people**: hire with security literacy as a explicit hiring criterion, even if not a dedicated security hire — "almost as good but security-literate" beats "best engineer, zero security knowledge" at this stage. Don't skip stages out of impatience, and don't over-invest in consultant/pentest spend before there's real usage/revenue to justify it. ## Lovable's built-in scanner — use it right Two modes, both free, unlimited runs: - **Basic scan**: RLS policy check, quick DB review, dependency audit. Fast, surface-level. - **Deep scan**: agentic, ~5+ minutes, looks for business-logic issues, access-control gaps, backend endpoint protection. Genuinely goes deeper on repeat runs because it has access to its own prior context — **a second run surfacing new findings is the scanner going deeper, not being flaky or inconsistent.** Don't get discouraged by this; run basic → fix → deep → fix → deep again as a normal cadence, not a one-shot. **Security Memory** (Project → Security tab → edit security memory): auto-populates after a deep scan, but you should also hand-author entries describing the app's actual critical areas ("this is a financial app with a payments flow and an auth module — treat these as high-stakes"). This makes subsequent scans targeted instead of generic. Update it as the app's risk profile changes — a role's permissions accepted as fine early on can become a real problem as the app grows, and a stale Security Memory won't flag that drift on its own. **Review dismissed/accepted findings periodically.** Accepting a finding is a snapshot judgment against the app's risk profile *at that time* — re-review the accepted list occasionally, especially after adding new roles, new data sensitivity, or new user-facing surfaces. **Cost efficiency**: chatting with the agent about a finding costs credits (fraud prevention — free-form chat-about-an-issue was being abused as a backdoor for free general chatting). Cheaper alternatives: use the (near-invisible) "fix selected" selector in scan results to fix specific accepted findings without a full "fix everything" pass; ask specific, context-loaded questions ("given my app does X, is finding Y actually exploitable?") rather than open-ended "what's wrong" — a targeted question burns fewer credits than one that makes the agent re-gather context from scratch. ## Architecture matters: RLS is not always your only defense layer - **Pre-TanStack Lovable apps** (built before ~May 2026): pure SPA architecture, frontend calls the database directly. **RLS is the only defense layer** — if a policy has a gap, there's nothing else standing between an attacker and the data. - **Post-TanStack Lovable apps**: requests go through an actual backend layer first, then to the database. This gives **defense in depth** — even if an RLS policy is wrong, a bad request often gets stopped at the backend layer before it ever reaches the DB. This also makes rate limiting practically implementable (ask the agent directly: "I'm worried about spam/DB-fill attacks, should I add rate limiting, where?"). **Practical implication**: when assessing a Lovable project's security, first establish which architecture generation it's on — this changes how much weight a given RLS gap actually carries. For an older SPA-style app with real users, migrating to TanStack is a meaningful security upgrade, not just a modernization — but weigh migration risk for apps with live users/data; for early-stage/no-users apps, migrating is close to zero-risk and worth doing sooner rather than later. **Explaining RLS to a non-technical stakeholder**: don't hand them raw SQL. Ask the Lovable agent "explain RLS to me and to my app specifically" — it can translate the actual policies into plain-language statements about who can see what, grounded in the real schema rather than a generic explanation. ## Minors / underage users Lovable's own platform policy: 13+ with parental account oversight; not built for under-13 use. If a project serves minors, check the specific jurisdiction's requirements (varies significantly by country) rather than assuming a single global standard applies. A workable pattern Lovable itself has used for school programs: pseudonymized accounts (generated placeholder names, not real names), disposable/time-boxed IDs, no way to link an account back to a real identity. Real names count as PII — if the project must collect them for minors, that's a higher-scrutiny bar, not a default choice.