Vibecode Rescue: supaflo.cc

supaflo.cc sells tools for music creators — a marketplace, a dashboard, creator tooling. It has been earning $387 a month, the listing says it was founded in June 2020, and the owner wants $2,500 to be rid of it. Thirteen people have made offers.

It scored 36.5 out of 100. Broken, with a confirmed critical in Data Access described below.

Observed on 2026-08-04 against a snapshot of the page, the shipped bundle, response headers, DNS and the legal pages. Signup was walked through on a real account.

The account you create is not theirs

Click sign up on supaflo.cc and you land on a unified sign-in screen headed BeatPhase, carrying a different company's logo:

One login for BeatPhase and Supaflo — marketplace, dashboard, and creator tools together.

The consent checkbox is not Supaflo's:

I agree to the BeatPhase Terms & Conditions and confirm I will not use the platform to promote or sell drugs, pornography, weapons, or engage in any illegal activity. Violations result in a permanent ban.

Below the button: "One account unlocks BeatPhase and the full Supaflo platform."

So a Supaflo user is a BeatPhase user, bound by BeatPhase's terms, on BeatPhase's identity system.

Supaflo's own privacy policy mentions BeatPhase zero times. Its terms mention BeatPhase zero times. The only appearance anywhere on the property is a feature chip on the landing page — ✓ BeatPhase Marketplace — where it reads as something you get, not as the company whose platform you are joining.

A user signing up here is accepting a contract they were never shown, with a company the product never names. That is the finding: the disclosure is absent at the exact moment consent is collected.

I stopped at that screen and did not complete registration, which is why A1 is scored on what a prospective user encounters rather than on what is behind the door.

The browser talks straight to the database — and the database answers everyone

The public page makes direct client-to-database calls: the browser queries a Supabase PostgREST API using the public key shipped in the site's own JavaScript, with client-specified filters and no bound on the result set.

Whether row-level security scopes what that key is allowed to read is not answerable from outside. Finding out means querying an API with real customer records behind it, so it happened under coordinated disclosure rather than in the black-box pass.

It is the worst case. Row-level security was not scoping the public key on the tables that hold user data. An anonymous visitor, using only the public key already in the page, could read customer records — names, email addresses, phone numbers and payment identifiers — alongside secret API keys belonging to those accounts. Some tables in the same schema were correctly protected, so this is a per-table gap rather than a switch left off everywhere. It is narrow, and it is the kind of thing that gets fixed in an afternoon.

This is a Confirmed Critical in Data Access. Cap 1 holds any product carrying one to 39 or below, so it fires — but it does not bite: zeroing B2 drops the raw total from 42 to 36.5, which is Broken on its own. The rescore did the work; the cap only guarantees it. The reproduction, the affected tables and the exposure counts went to the operator in a private report and are not in this piece — and after what happened next, they are not going to be.

A live product taking money every month, leaking its paying customers' personal data and secret keys to anyone who loads the page, is not a matter of degree. It is the single finding that should stop everything else.

Nothing protects the pages

The site serves none of the standard security headers:

content-security-policy      MISSING
strict-transport-security    MISSING
x-frame-options              MISSING
x-content-type-options       MISSING
referrer-policy              MISSING
permissions-policy           MISSING

Not even HSTS, on a property handling creator accounts and payments.

What it gets right

• Best-practices 100 and SEO 100 on mobile Lighthouse — full marks on both, which is rare.
• Accessibility 95, with two failures.
• MTA-STS is present, which is an unusual thing to bother with.
• SPF is published and DMARC carries a reporting address, so somebody set mail up deliberately.
• A real 404 that names the problem and leaks no framework detail.
• Cancellation is described in the terms.

The mail and SEO hygiene sitting next to zero security headers is a strange pairing. Somebody who knew to publish MTA-STS did not set X-Content-Type-Options.

Where the trust surface stops

The terms name an entity and describe cancellation. Past that it thins out fast. Jurisdiction, retention period, deletion path, deletion timeline, refund policy, security contact and a last-updated date are all absent.

The sole published contact is damncabo@gmail.com. It receives mail — a personal Gmail address does — but it is off-domain, and it is the entire support channel for a product taking money every month.

The dates don't agree

The listing says founded 2020-06-05. The web archive's first capture of supaflo.cc is 2025-08-05, and there are six captures in total.

That gap has innocent explanations — a rebrand, a domain move, a site that robots.txt kept out of the archive for years. It is not evidence of a false claim. It is a note that the observable public record of this product starts ten months ago, and the age claim rests on something other than the archive.

The score

One dimension on that card stays Unknown, and it should be named rather than left to the reader. Payments Integrity scored 4.5 of 9 — half weight, the convention for Unknown — because I stopped at the sign-in screen. The checkout, the webhook handling and whether prices are enforced server-side all sit behind a registration I did not complete. Nobody outside the company can score that, including the thirteen people who have made offers.

What I'd fix first

1. Rotate every exposed secret key and enable row-level security on the tables the public key can reach, denying the anonymous role by default. This was the first item in the private report and it was declined; it is still the first item. Until it is done, every affected key and every affected user record should be treated as compromised.
2. Disclose the BeatPhase relationship in the privacy policy and the terms. Users are accepting a third party's contract and the documents do not say so.
3. Add the six security headers. An afternoon at the CDN.
4. Move support off a personal Gmail to an address on the product's own domain.
5. Write the retention, deletion and refund sections. All three are missing outright.

Disclosure

The rule for this series is that a real vulnerability goes to the operator privately, and publishes once it is fixed or once a stated window runs out. Neither of those is what happened here.

A private report went out on 2026-08-05 with the reproduction, the affected tables and the exposure counts. The operator acknowledged it and declined to fix it.

So the finding described above is live as of today. That changes what I will print; it does not change whether I print. The reproduction, the table names and the counts stay out of this piece permanently rather than pending a fix, because publishing them hands the next reader a working exploit against people who did nothing wrong. What does not stay out is that the exposure exists — the customers are the ones carrying it, and nobody had told them.

If you have an account on supaflo.cc: treat any API key you generated there as public and rotate it anywhere else you have used it, and assume the name, email address and phone number on the account are exposed. I would rather point you at a fix. I asked for one.

These audits are free and public; the paid version is a Code Health Check, and the rescue work after it is Track 03 on my services page.