DEV Community: Keymel Gaston

Missing RLS: The Most Underrated Breach Cause of 2026

Keymel Gaston — Sat, 12 Sep 2026 23:19:25 +0000

You know why there are so many breaches in databases? Perfect, me neither. Let's find out in a few minutes.

Everyone worries about encryption. Almost nobody worries enough about the one thing that's actually been breaking production databases all year: a table with Row Level Security simply left off.

I ran into this while researching how to safely migrate Firestore Security Rules into Postgres RLS policies for a side project. What started as "how do I translate this correctly" turned into "oh, this is the single most common way people get breached right now." Here's what I found.

The pattern, with real numbers

🐞 CVE-2025-48757 (May 2025). 303 endpoints across 170 applications built with Lovable, an AI app-building tool, had Supabase tables publicly readable because RLS was never enabled. Not misconfigured — never turned on.

🕵️ March 2026. A database belonging to an AI platform was exfiltrated after an attacker found an instance with, again, missing RLS. Admin emails and internal schema metadata were exposed.

📡 Ongoing. Security researchers have shown that thousands of Supabase instances can be queried with nothing more than a plain curl request and the public "anon" key, dumping entire tables. Estimates put it at hundreds to thousands of misconfigured instances, globally, right now.

Multiple 2025-2026 sources converge on the same line:

Data protection in Supabase is roughly 90% access control, 10% encryption.

Encryption isn't the weak point. The access control layer is — specifically, the step where someone creates a new table and either forgets to turn RLS on, or writes a policy that's more permissive than they think it is.

It's not a new mistake, just a new stage

This isn't unique to Supabase or even to 2026. Firebase had its own version of the exact same failure: a documented, verified leak exposed plaintext passwords and sensitive data belonging to over 1.8 million users, across more than 900 mobile apps, because Realtime Database instances were left publicly accessible — spanning health, finance, and education apps.

Same root cause, different technology: a control-access layer that someone had to configure by hand, and didn't configure correctly.

Why this keeps happening

It's easy to get right once, and easy to forget under pressure. Supabase actually improved here in 2026 — RLS is now enabled by default on new tables, and the dashboard flags tables that don't have it. That's a real fix for the "I forgot" case. But it doesn't help with the harder case: recreating access logic that used to live somewhere else.

Migrations are exactly when this goes wrong. If you're moving from Firestore, your access control used to live in Security Rules — a completely different language, with a completely different mental model, often mixing "who can access this" with "does this data have the right shape" in the very same rule. Rebuilding that from scratch, by hand, under the time pressure of a migration, is precisely the moment this class of bug is most likely to slip through.

And almost nobody automates that translation. I looked. Guides for migrating off Firestore, even ones published this year, list "recreate your security rules as RLS policies" as a manual checklist item — nobody's shipping something that does it for you. rebasepro/rebase sidesteps the whole problem by having you define policies once in its own DSL instead of translating what you already have. supashim has rule translation listed as "in active development," with no public code yet.

Part of why: Firestore rules genuinely mix two concerns that Postgres keeps separate — access control (RLS) and data shape validation (CHECK constraints, column types). Translating well means untangling that mix first, not just mapping syntax A to syntax B. It's a semantic problem, not a find-and-replace one.

What this actually means if you're migrating

If you're moving off Firestore (or any system where security rules were baked into the data layer), don't treat the security side as an afterthought you'll "get to after the data's in." The data being correct and the access control being correct are two separate risks, and the second one is the one with a CVE number attached to it right now, not a hypothetical.

A few things that seem to actually help, based on what's out there:

Default to deny, never to a guessed permissive policy, for any rule you can't confidently translate.
Treat every generated policy as a draft that needs human review, not something to apply automatically.
If you're on Supabase specifically, lean on the fact that RLS is now on by default for new tables — but don't assume that saves you if your migration path creates tables outside the normal flow.
Tools like pgrls (a static RLS linter with dozens of rules for catching tenant-scoping bugs and inverted auth checks) are worth running against whatever you end up with, translated or hand-written. ## The uncomfortable part

None of the breaches above were exotic attacks. No zero-days, no clever exploits — just a curl request against a table that should have had a policy on it and didn't. The failure mode is boring, which is exactly why it keeps happening: boring mistakes don't feel urgent enough to build tooling around, until they show up in a CVE.

Have you had to rebuild access control logic during a database migration? Curious whether you did it by hand, found a tool, or just... didn't think about it until later.

Built at 3am, still holding the morning coffee ☕

Why Nobody Has Solved Firestore-to-Postgres Migration Well

Keymel Gaston — Sun, 06 Sep 2026 21:07:34 +0000

Search for "Firestore to Postgres migration tool" and you'll find the same pattern over and over: a repo with good intentions, some initial traction, then silence. This isn't bad luck. It's a structural pattern, and it's worth understanding why before anyone tries to fix it.

The graveyard

Let's start with the facts. Here are the real attempts that exist, or existed, to tackle this problem:

Tool	Peak traction	Status today
`fireway`	282 ⭐ / 47 forks	Archived by its own maintainer
`mad-migration`	~30 ⭐	Frozen since 2020
`pydantic-firestore`	0 ⭐	Confirmed inactive
`FireSync`	brand new	v0.1.x, too early to tell

fireway is the most illustrative case. A Firestore schema migration CLI, inspired by Flyway, with real traction — 282 stars and 47 forks don't happen by accident. Throughout 2022 and 2023, real users actively asked whether the project was still alive. Eventually, the maintainer himself answered honestly:

"This repo is unmaintained. I'll archive it for clarity."

The community didn't fully give up — at least two forks emerged to keep it going — but the original project, the one with the most traction, was abandoned by its own creator.

mad-migration tried to solve migrations between different database types. Its last documented activity dates to 2020: issues asking for column indexing support when migrating to MongoDB, extra-table support via YAML, async drivers. None resolved since.

pydantic-firestore showed up more recently and is already confirmed as inactively maintained, with zero stars on GitHub.

FireSync is the newest and most ambitious attempt — it brings a Terraform-style workflow (pull → plan → apply) for managing indexes and TTL policies with version control. But it's still at version 0.1.x. Too early to know if it'll meet the same fate as its predecessors.

None of these projects failed for lack of technical skill. fireway solved the problem reasonably well for a lot of people. The underlying pattern is something else entirely.

Why the pattern repeats

🔁 It's a one-time event, not a recurring one. A company migrates from Firestore to Postgres once in the life of its project. It doesn't need to do it again. That breaks the recurring-revenue model that sustains most software — and it breaks the maintainer's own motivation too: they wrote the tool because they were migrating, solved their own problem, and never had a second case to keep polishing it for.

🔒 Nobody trusts production data to a black box. One real company (Traba, an industrial staffing platform) publicly documented its own migration:

A full year of work. A team of roughly 12 engineers. Built entirely from scratch — trigger-based replication, per-collection reconciliation scripts, retry logic for referential integrity, a complete rollback plan.

They didn't use any external tool. The risk of getting production data wrong was too high to trust to some unknown GitHub project.

🧠 The hardest step resists automation. Deciding whether a nested field belongs in a separate table or stays as jsonb isn't a purely technical call — it depends on how that data will be queried down the line, something only someone with business context can judge well. Supabase's own community discussion on this exact kind of migration explicitly recommends against over-normalizing upfront. That's a judgment call, not an algorithm.

🧩 The market is fragmented by technology. Firestore→Postgres, MongoDB→Postgres, DynamoDB→Postgres are, in practice, distinct problems with different SDKs and data models. None is big enough on its own to sustain a robust tool, while a generic "any NoSQL to any SQL" migrator is a far more ambitious project than any solo maintainer can sustain in their spare time.

🏢 The platforms that own the data have no incentive to solve it. Neither Firebase nor Supabase builds a complete migration tool — and that's not negligence, it's design. Firebase/Google is stable enough that most users never need to leave. Supabase invests in securing whoever already arrived (RLS enabled by default on new tables, for instance) but not in translating what someone brings over from Firestore — that only benefits someone leaving the competitor.

💸 And the consultancies that solve it well have no incentive to automate themselves. Certified AWS consultancies offer Firebase-to-Supabase migrations as a packaged service. Agencies specializing in MongoDB→Postgres report 30+ projects delivered, priced in the thousands of dollars each. They all sell engineer-hours doing the work by hand. Automating that process would cannibalize their own high-margin business.

The pattern repeats beyond Firestore

This isn't exclusive to Firestore. One engineer described helping 34 different companies migrate from MongoDB to PostgreSQL over 8 years, always describing the same sequence: initial excitement about being "web scale," then slow queries, then an unsustainable bill, then finally the migration. Documented cases include companies that spent $60,000 with full senior engineering teams. On the DynamoDB side, some companies migrated there to save money and ended up spending $200,000 learning architecture lessons before finding the right access pattern.

The root cause is always the same: NoSQL databases are designed around the initial use case's queries, but the business changes over time, and the way you interact with the database becomes unmanageable. It's what happens when development speed is chosen over relational structure early on, and the business matures faster than the schema.

What actually changed recently

There's one piece that didn't exist just a couple of years ago, and it might explain why this problem could finally get a sustainable solution: reasonably good, cheap LLMs. The most serious attempts at solving schema inference with AI help (instead of fixed rules or training a model from scratch) only started appearing in 2025-2026 — the first tools capable of reasoning with something resembling judgment about ambiguous field names, types, and implicit relationships, without needing a training dataset or years of hand-written rules.

That alone doesn't solve the incentive problem — but it does solve the technical piece that was missing before.

The uncomfortable conclusion

This isn't a market gap nobody noticed. Talented people noticed it, more than once. The gap stays open because the combination of factors surrounding it — one-time event, no platform incentive, need for trust, need for human judgment, fragmented market — makes it genuinely hard to turn into a sustainable product, not just a script that works once.

That doesn't mean it isn't worth trying. It means whoever tries should start knowing exactly why the previous attempts didn't survive, instead of finding out the hard way, a year in, with an archived repo and an "I don't have time to maintain this anymore" message.

Have you had to migrate from Firestore (or any NoSQL database) into a relational world? I'd genuinely like to hear how you handled it — by hand, with one of these tools, or by paying someone else to do it.

Built in one afternoon, still holding the morning coffee ☕

Astro 7.3's Smallest New Feature Might Be the Most Useful One for Testing

Keymel Gaston — Fri, 04 Sep 2026 21:34:38 +0000

Astro 7.3 shipped a few days ago. Most of the attention is probably going to the bigger stuff, but there's a one-line change in the CLI that I think is more useful day-to-day than it looks: astro preview finally got an --ignore-lock flag.

Some background first

Astro 7.0 introduced a lockfile for astro dev — every time you start a dev server, Astro writes a small file recording its URL, port, and PID, specifically so AI coding agents don't accidentally spin up duplicate dev servers for the same project while you're already running one.

Reasonable problem to solve. But it had a side effect: if you wanted to run a second dev server on purpose — say, a throwaway instance with verbose logging while your main one keeps running — Astro would just error out. The lockfile didn't know the difference between "an agent accidentally duplicating" and "a human doing this deliberately."

Astro 7.1 fixed that for astro dev with --ignore-lock, which skips the lockfile check entirely so a second instance can run alongside the first. Astro 7.2 then added the same lockfile protection to astro preview — but forgot the escape hatch. So you'd hit the exact same wall, just one command later.

Astro 7.3 closes that gap:

astro preview --ignore-lock

Why this specifically matters for testing

The Astro team calls out the actual use case in their own release notes: Playwright and other E2E testing workflows that need multiple preview servers running at once.

If you've set up playwright.config.ts with a webServer block (the way most Astro + Playwright setups do it), the test runner spins up its own preview server automatically. If you're also running your own preview server locally — to manually poke at the same build, or running two suites against two different ports — you'd hit the lock before 7.3, full stop.

I just went through setting up a Playwright suite for a recent project, and this is exactly the kind of small friction that doesn't show up until you're mid-debug and confused about why your test runner won't start. Nice to see it closed less than a year after the original lockfile shipped.

Small feature, but worth knowing

Nothing here changes how you build a site. It's the kind of change that's easy to skim past in a changelog and then rediscover the hard way three months later when you actually need it. If you're running Playwright against an Astro project, it's worth having this in the back of your mind before it becomes a "why is this broken" moment instead of a one-line fix.

Written at 3am, fueled by coffee and questionable life choices ☕

I Went Looking for Why Lenis Beat Locomotive Scroll. The Real Story Surprised Me.

Keymel Gaston — Tue, 01 Sep 2026 22:58:54 +0000

I use Lenis for smooth scroll in most of my projects, and I'd always assumed it just won a popularity contest against Locomotive Scroll — more stars, more downloads, moved on. So I went looking for the actual reason. What I found was more interesting than "it's more popular," and it ends with a twist I didn't expect.

Act 1: The problem nobody was talking about

For years, most smooth-scroll libraries — including older versions of Locomotive Scroll — used what's basically a clever hack: fix a wrapper element, then apply a CSS transform to it on every frame, based on an eased scroll value. It looks smooth. It works.

It also means the page never actually scrolls. The browser's real scroll position stays put; you're just visually translating content around.

That hack quietly breaks a handful of things developers don't notice until they ship:

position: sticky — stops working correctly, because the element isn't really moving through a real scroll container
scroll-snap — same problem
Native browser search (Ctrl+F) and anchor links — can behave unpredictably when the "scroll" is fake
Screen readers and accessibility tooling — lose meaningful context
GPU load — large, repeated transforms aren't free

Lenis took a different approach on purpose: keep the browser's real, native scroll active, and layer interpolation on top of it — actual scrollTo calls, eased, not a transform illusion. From Lenis's own site:

"What began as an internal tool for syncing WebGL and the DOM is now the default smooth scroll across the industry — even powering libraries like Locomotive Scroll. The smoothness was a happy accident."

That's the origin story, by the way — Lenis wasn't built to "win" the smooth-scroll library wars. It was an internal tool at a WebGL agency (darkroom.engineering) for syncing DOM scroll with WebGL canvases, and the smooth-scroll behavior came along for the ride.

Act 2: The twist

Here's the part that surprised me. I went looking for a "Locomotive Scroll vs Lenis, which is better" comparison. What I found instead: Locomotive Scroll v5 is built on top of Lenis.

Not "inspired by." Not "similar architecture." Built on it. Their own release notes say it directly:

"Version 5 is a complete rewrite of Locomotive Scroll, now built on top of Lenis."

And their docs summarize their own history bluntly: "This library has evolved considerably over the years. From jQuery to vanilla ES6, from custom engines to Lenis foundation."

The reasons they list for the rewrite read like a direct admission of the exact problems the old transform-hack approach caused:

"No more greedy CSS transforms breaking your layouts"
"Works perfectly with position: sticky — No conflicts, no workarounds"
Bundle size dropped from ~12.1kB to 9.4kB gzipped

This isn't really a story about one library beating another. It's a story about the ecosystem converging on a better-solved primitive. Locomotive didn't lose — they made the pragmatic call to stop maintaining their own lower-level scroll engine (which had real, filed bugs — GitHub issues #519 and #532, among others) and build their higher-level features (parallax, intersection detection) on top of infrastructure the community had already gotten right.

For context on scale: Lenis sits at roughly 14k GitHub stars with 35 contributors, npm downloads growing from ~93k/month to ~343k/month over the past year. Locomotive Scroll has ~8.6k stars, 25 contributors. Not a landslide — but a clear enough gap that "we'll build on the leader" made sense for Locomotive's team.

Act 3: The thing that might make this whole comparison irrelevant

While Lenis and GSAP's ScrollTrigger were winning their category, the browser itself started doing some of this natively. CSS now has animation-timeline: scroll() and animation-timeline: view() — scroll-driven animations with zero JavaScript.

.reveal {
  animation: fade-in linear;
  animation-timeline: scroll();
  animation-range: entry 0% cover 30%;
}

Chrome's had full support since 2023. Safari joined in September 2025. And this is real enough that a design agency wrote publicly: "We've removed framer-motion from three client sites this year because of them [native scroll-driven animations]." That's not a hypothetical threat — that's a JS animation library actually getting removed from production sites.

But — and this is the part that matters — it's not a clean "native CSS wins" story either. The nuance, well put by one source I found:

"Use native CSS when the animation is linear, depends on scroll or viewport position, and doesn't require programmatic timeline control (play, pause, reverse, scrub) or complex sequencing. GSAP remains necessary for advanced animation sequencing, reverse timelines with speed control, and custom physics."

And specifically for Lenis: native scroll-driven animations sync an animation's progress to scroll position. They don't smooth the scrolling motion itself. That's a different job — the one Lenis actually does. Native CSS doesn't touch it.

There's also a real reason this took Firefox until 2026 to catch up (still behind a flag in stable, as of writing). I checked Mozilla's own bug tracker — their official standards position is supportive, this isn't a "we disagree with the spec" situation. It's scale: the meta-bug tracking implementation has 30+ dependent sub-bugs, including real correctness issues (one engineer explicitly blocked shipping on a bug involving scroll animations breaking a common CSS custom-property technique) that Chrome's larger engineering team could parallelize through faster. A frustrated developer's post on Mozilla Connect noted a related, older bug has been open for almost a decade.

Where that leaves things

Lenis didn't win by being more popular — it won by fixing a real architectural problem (fake scroll breaking accessibility and native browser features) that its "competition" eventually admitted to having too, and built on top of instead of continuing to fight. Meanwhile, native CSS is genuinely eating the simple end of scroll animation — the reveals, the parallax, the progress bars — while leaving the complex, sequenced, physics-driven work (and the actual job of smoothing scroll itself) untouched.

It's not a popularity contest and it's not "native CSS will kill JS libraries" either. It's two different tools settling into the jobs they're actually good at.

I write about this stack (Astro + GSAP + Lenis) semi-regularly — my last post covered why Astro can't type named slots yet, and the one before that covered 4 production bugs common to this exact combo. If you've got a scroll-animation war story of your own, I'd genuinely like to hear it in the comments.

Can You Type Named Slots in Astro? (Short Answer: Not Yet)

Keymel Gaston — Fri, 28 Aug 2026 20:54:36 +0000

Someone asked me this in the Astro Discord recently, and I went looking for a real answer instead of guessing. Sharing it here because it's a question that comes up a lot, and the honest answer isn't what most people expect.

The question

You can type a component's props in Astro easily:

interface Props {
  title: string;
  description: string;
}

And your editor gives you autocomplete and errors if you get it wrong. Great.

But what about named slots?

---
type Props = {
  children: string;
}
---
<slot />
<slot name="foo" />

Can you type the foo slot the same way — so TypeScript warns you if a consumer misspells the slot name, or passes the wrong kind of content?

The short answer

You can't. Not properly, at least not yet.

Astro's Props typing only covers the default slot, via children:

type Props = { children: any };

There's no equivalent for named slots. This isn't something hidden in the docs that you missed — it's a real, acknowledged gap in the framework.

It's not just me saying that

There's a GitHub RFC discussion proposing typed slots, going back to December 2022. An Astro core maintainer replied directly:

"Typed slots is already something we're planning, though it's currently not in our roadmap. The tricky part of this is mostly the implementation, TSX doesn't have proper tools for this and our current slot implementation is challenging to support, we're still investigating the way to go for that."

That's from 2022. As of writing this, it's still not implemented. The RFC author followed up in 2024 saying the problem still needs addressing — no resolution since.

Why it's actually hard, not just neglected

Props are easy to type because they're a flat object — { name: string, age: number }. TypeScript has handled that shape forever.

Slots aren't data, though — they're markup being injected into a specific spot in a component's template. That's a fundamentally different kind of thing to describe than "this value should be a string." TSX itself doesn't have great tooling for this, and Astro's internal slot implementation adds its own layer of complexity on top. It's less "nobody got around to it" and more "the tools to do it properly don't fully exist yet."

What you can actually do today

Two practical options, neither of them compile-time type safety, but both better than nothing:

1. Document it in a comment. Not enforced, but at least visible to whoever uses your component:

---
// Slots: default, "header", "footer"
type Props = { children: any };
---

2. Runtime checks with Astro.slots.has():

---
const hasFooter = Astro.slots.has("footer");
---
{hasFooter && <slot name="footer" />}

This catches missing slots at runtime, not compile time — but if a slot is required for your component to render correctly, at least you can branch on whether it was passed.

The actual lesson here

Not every "how do I do X" question has an answer. Sometimes the honest answer is "you can't, here's why, here's the closest workaround" — and that's more useful than a fake solution that falls apart the moment someone tries it. If you're ever unsure whether a limitation is you missing something or a real framework gap, checking the RFC discussions and issue trackers directly is worth the extra five minutes.

If you're building with Astro + GSAP + Lenis specifically, I write about that stack a bit — my last post covered 4 common bugs in that combo. Happy to talk through Astro TypeScript quirks in the comments if you've hit others like this one.

4 Motion Design Bugs That Break Astro + GSAP + Lenis Sites in Production

Keymel Gaston — Sun, 23 Aug 2026 22:04:20 +0000

I got tired of debugging the same four things every time I built a motion-design landing page with Astro, GSAP, and Lenis — so I wrote them down. Here's each bug, what causes it, and how to fix it.

1. Scroll-triggered animations that never fire

How to spot it: you scroll to a section, and the animation that's supposed to play doesn't. No console error — the element just sits in its "before" state forever.

The cause: Lenis replaces native scrolling with a virtual, smoothed one. GSAP's ScrollTrigger has no built-in awareness that Lenis exists — it's still listening for native scroll behavior Lenis has effectively taken over.

The fix:

lenis.on("scroll", ScrollTrigger.update);

gsap.ticker.add((time) => {
  lenis.raf(time * 1000);
});

gsap.ticker.lagSmoothing(0);

Do this once, at setup. Do it per-section instead and you'll eventually forget one — which is exactly how this bug ships to production.

2. Images that fade in as blank boxes

How to spot it: a smooth, well-eased fade-in animation... revealing nothing. The image pops in abruptly partway through, or right after the animation finishes.

The cause: the animation triggers on DOMContentLoaded, component mount, or scroll-into-view — none of which guarantee the image has actually finished downloading and decoding.

The fix:

async function waitForImage(img) {
  if (img.complete) {
    await img.decode?.().catch(() => {});
    return;
  }
  await new Promise((resolve) => {
    img.addEventListener("load", resolve, { once: true });
    img.addEventListener("error", resolve, { once: true });
  });
}

Await this before starting the fade. One helper function, one fewer confusing bug report.

3. Buttons that stop responding for no visible reason

Two separate causes here — worth checking both.

3a — a decorative layer is eating the click.

An animated background shape or overlay ends up in a higher stacking context than an interactive element near it. The button looks normal. It just doesn't respond.

- z-index left to chance, decided per component
+ pointer-events: none on every purely decorative element, always

3b — a React/Vue island hasn't hydrated yet.

With lazy hydration (client:visible, client:idle), there's a real window where an island's HTML is on the page but its listeners haven't attached. A click in that window isn't delayed — it's lost.

const [hydrated, setHydrated] = useState(false);
useEffect(() => setHydrated(true), []);

<button disabled={!hydrated}>
  {hydrated ? "Click me" : "Loading…"}
</button>

Don't just hope the click lands after hydration — disable the element until hydration is confirmed. This race can pass casual manual testing and still fail reliably under real load — it's the kind of thing that's easy to miss until you have automated tests hitting it under real concurrency.

4. SEO and Lighthouse scores that don't hold up

The most common individual causes:

og:image set to a relative URL — silently fails the Open Graph spec, which requires an absolute URL
No base URL configured, so canonical links can't resolve
Missing alt text, skipped heading levels, no sitemap

The fix: centralize your <head> in one layout every page uses, resolve image and canonical URLs to absolute paths explicitly, and generate a sitemap.

One honest note on Lighthouse scores

If you're running Lighthouse on a site with real scroll-driven animation and you're not hitting a perfect 100 on Performance — that's expected. A 100 with heavy motion actually running is rare; it usually means the animation isn't doing much. A defensible 80s–90s score with genuine motion design running is more honest than a suspiciously perfect one.

I put all four of these — tested, with automated regression tests, demonstrated live rather than just described — into a full Astro + GSAP + Lenis landing page template. The live demo is here if you want to see them in action, and the kit itself is on Gumroad if you'd rather start from a base that already has this solved.

Happy to answer questions about any of these in the comments — especially the hydration race in #3, that one surprised me too.