DEV Community: ShipTested

A Success URL Is Not Proof of Payment

ShipTested — Sat, 18 Jul 2026 09:47:33 +0000

A customer finishes checkout and the payment provider sends their browser back
to /success. Your app shows a green check. That is useful user experience. It
is not evidence that the order was paid.

The browser controls the URL it visits. It can revisit that URL, change its
query string, share it, or open it without completing checkout. If visiting
/success?paid=true creates access, the paywall is a URL convention—not an
authorization boundary.

The launch check is simple:

A success-page visit must create zero entitlements.

Reproduce the failure

The ShipTested public teaching harness contains this deliberately unsafe
handler:

export function vulnerableHandleSuccessPage({ query, entitlements }) {
  const params = new URLSearchParams(query);

  if (params.get("paid") === "true") {
    entitlements.push({
      userId: params.get("user_id"),
      source: "browser-redirect",
    });
  }
}

Nothing here establishes that a payment provider accepted an order. Both
paid and user_id came from the browser. A visitor can type:

/success?paid=true&user_id=user-b

The exploit test calls the handler with that query and verifies that it creates
an entitlement. Run it with:

npm run test:failures

One naming detail matters: the exploit test passes when it successfully
reproduces the vulnerable behavior. It is evidence of a failure, not launch
approval.

This example is intentionally small. It does not claim that every checkout
integration has this bug. It gives you a deterministic way to recognize and
test one unsafe pattern in your own app.

State the invariant before choosing the fix

The fixed example makes the success page informational only:

export function handleSuccessPage() {
  return {
    status: 200,
    access: "pending-verified-webhook",
  };
}

Its launch test supplies the same hostile query and checks two outcomes:

assert.equal(result.access, "pending-verified-webhook");
assert.equal(entitlements.length, 0);

The model still returns status 200 and pending-verified-webhook. It
demonstrates an informational response without creating access, regardless of
the supplied query parameters.

Run the green checks with:

npm run test:launch

The checkout check passes only when a success-page visit creates no
entitlement.

What should create access instead?

Put the authority on the server side. A common payment flow looks like this:

An authenticated server endpoint maps an internal plan name to an allowlisted provider product or variant.
The server attaches the signed-in internal user ID as checkout metadata. The browser does not choose the owner, price, or variant as trusted data.
The success page shows a pending or processing state. It may read current entitlement state, but it does not write it.
A server-side verified payment event creates the entitlement. The planned full ShipTested reference flow uses a signed webhook whose event type, paid status, store, variant, test mode, order ID, and internal user ID are checked before a state change.
Duplicate deliveries become no-ops through a database-enforced boundary such as a transaction and appropriate unique constraints.

A signed webhook is not the only possible provider architecture. Some
integrations retrieve and verify a checkout session server-to-server after the
redirect. The invariant stays the same: browser-controlled redirect data does
not grant access by itself.

The public checkout example proves only the negative redirect invariant. It
does not yet contain the server-created checkout endpoint. That endpoint,
durable database constraints, refund handling, and provider-specific
integration belong to the full reference repository.

The public webhook model checks only that the custom user ID is a non-empty
string. A production flow must resolve it to an eligible internal record before
granting access.

Run the check against your staging app

Use a staging environment and test data:

Copy the checkout success URL.
Open it in a fresh session without placing an order.
Refresh it several times.
Add or change parameters such as paid, status, plan, variant, and user_id.
Inspect the entitlement table or access-control result after every attempt.

The passing result is zero new access. A message saying “payment processing” is
fine. A new entitlement, paid role, license, credit balance, or protected
download is a failure.

Then complete a sandbox purchase and verify the separate server-owned
fulfillment path. That second step matters, but it is outside what the small
redirect harness proves.

The boundary of this proof

The repository is a dependency-free Node.js teaching harness with in-memory
state. It demonstrates an unsafe redirect and a fixed invariant through
executable tests. It is not a production payment integration, a security audit,
or a certification. Passing this one test does not make an app ready to sell.

It does remove one dangerous ambiguity: the browser may report where it landed.
It does not decide who paid.

Inspect the exact test

Run the broader launch-readiness checklist

Sources: Lemon Squeezy — Taking Payments,
Create a Checkout API,
and Passing Custom Data.

ShipTested uses AI heavily to produce this material and verifies the technical
examples by running them. There are no fake testimonials and no guaranteed
outcomes — the point is that you run the tests yourself instead of trusting an
author.

Test Your Supabase RLS With Two Users Before You Sell

ShipTested — Sat, 18 Jul 2026 09:20:04 +0000

Your prototype works. That is not the same as safe to sell.

The dashboard opens. User A sees User A’s documents. User B sees User B’s
documents. That looks like data isolation, but it may only prove that the page
requested or displayed a filtered result.

If the database still accepts a direct request for another account’s row, the
boundary has already failed. User B does not have to use the screen you
designed. They can call the same data API and request User A’s row by ID.

The useful launch question is concrete:

Can User B read User A’s row?

Start with a red test

The ShipTested public example makes this failure visible with a small Node.js
20 teaching harness. It has no package dependencies.

npm run demo
npm run test:failures
npm run test:launch

The deliberately vulnerable function returns every document it receives. It
ignores the requesting user:

return [...rows];

The exploit test asks for documents as User B and checks whether a row owned by
User A is present.

When that test passes, it means the vulnerable behavior was successfully
reproduced. It is a red exploit demonstration, not launch approval.

The fixed policy model makes the intended invariant explicit:

return rows.filter((row) => row.userId === requestingUserId);

Its launch check expects User B to receive only doc-b, never doc-a. Run
npm run test:launch to exercise the fixed invariants. Read both versions side
by side; the diff is the point.

Move the invariant to the database

A JavaScript filter can explain the rule, but it cannot enforce a Supabase
database boundary. In a real project, Row Level Security must be enabled on the
relevant table, and the applied policies must match the operations your
application permits.

The example includes this minimal SELECT policy shape:

alter table public.documents enable row level security;

create policy "users can read their own documents"
on public.documents
for select
to authenticated
using ((select auth.uid()) = user_id);

This says that an authenticated request may select a document only when the
authenticated user’s ID matches user_id.

It is intentionally narrow. It does not define INSERT, UPDATE, or DELETE
policies, and it does not account for your project’s grants, schema, ownership
rules, functions, or other tables.

That boundary matters: the repository’s JavaScript check is a policy model. The
SQL is an example policy shape. Neither proves that your live migrations are
applied correctly or that your Supabase project is ready to launch.

Run the two-user test against your project

Use two ordinary test accounts and the same client path your application uses:

Sign in as User A and create a private row.
Save that row’s ID.
Sign out, then sign in as User B.
Through the normal data API, request User A’s exact row ID.
Repeat the isolation check for every operation your app permits: insert, update, and delete as well as select.
Sign back in as User A and confirm the intended own-row flow still works.

Do not use a service-role key for this test. It bypasses RLS and cannot show
what an ordinary authenticated user is allowed to do.

Do not run the test with production data. Synthetic users and rows are enough.

For the read case, the passing invariant is simple:

User B receives zero rows owned by User A, while User A can still retrieve
the row.

Both halves matter. If neither user can read anything because the query or
migration is broken, you have not demonstrated correct isolation.

For mutations, assert the state after each request. User B must not be able to
create a row attributed to User A, change User A’s row, or delete it. User A
should still be able to complete each operation the product intentionally
supports.

If User B receives or changes User A’s data, keep the exact request, response,
identities, and minimal fixture. Turn that reproduction into a test before
changing the policy. A stable red case gives you evidence that the fix
addresses the failure you actually found.

Know what green does—and does not—mean

A passing two-user check is evidence for one tested invariant on one applied
database path.

It is not a security certification.

It does not automatically cover every table, storage bucket, RPC, view, server
route, or privileged function. It also does not prove that future migrations
preserve the policy.

Keep the test in the launch suite and run it when the schema or authorization
path changes. Add cases as the product adds operations.

The goal is not to claim that an app is “secure.” The goal is to preserve a
falsifiable statement:

User B cannot read or mutate User A’s rows through the ordinary authenticated
path, and User A can still complete the intended flow.

Your prototype working is the start. A red/green isolation test is evidence you
can use before you sell it.

Inspect the exact test

Run the broader launch-readiness checklist

Sources: Supabase Row Level Security
and database testing.

One Webhook, Five Deliveries, One Entitlement

ShipTested — Sat, 18 Jul 2026 08:30:03 +0000

A customer can complete checkout once while your webhook handler receives the
same event more than once. If every delivery creates access again, one purchase
can produce duplicate licenses, seats, credits, or subscription records.

The launch check is concrete:

Take one valid, signed order webhook. Deliver the exact same body five times.
The result should still be one processed-event record and one intended
entitlement.

A webhook signature is necessary. It is not idempotency.

What the signature proves—and what it does not

A valid signature tells your handler that the raw request body matches a
message signed with the configured webhook secret. It helps reject forged or
modified payloads before they change state.

It does not tell you that the message is new.

Every repeated delivery can carry a valid signature because it is an authentic
copy of the same event. A handler that verifies the signature and then blindly
calls grantAccess() can still grant access five times.

In the deliberately vulnerable ShipTested example, the handler parses the body
and appends an entitlement on every call. Replaying the fixture five times
leaves five entries:

same order webhook ×5
entitlements.length === 5

That is the failure we preserve as a reproducible red test.

Define the invariant before the implementation

The fixed example starts with an invariant:

For one accepted order_created event and one expected product variant,
repeated sequential delivery changes entitlement state once.

The handler verifies the HMAC signature against the unmodified raw body before
mutation. It then checks the fields this teaching fixture expects:

event name is order_created;
resource type is orders;
order ID is present;
payment status is paid;
store ID matches;
variant ID matches;
order and item test mode match the configured environment;
the custom internal user ID is a non-empty string.

A signed payload for an unexpected variant grants nothing. So does an invalid
signature.

After those checks, the example creates a stable key from the event name,
resource type, and order ID:

const eventKey = `${eventName}:${order.type}:${order.id}`;

The first accepted delivery records that key and sets the intended entitlement.
Later deliveries with the same key return duplicate-no-op.

The five-delivery test

The fixed test signs one raw JSON body once, then sends that same body and
signature through the handler five times sequentially.

Its expected outcomes are explicit:

1. granted-once
2. duplicate-no-op
3. duplicate-no-op
4. duplicate-no-op
5. duplicate-no-op

processedEvents.size === 1
entitlements.size === 1

That is stronger evidence than clicking through checkout once and looking at a
success page. The test forces the duplicate-delivery path and records the
invariant in code.

Clone the teaching harness and run:

npm test
npm run test:launch

The repository contains both the vulnerable reproduction and the fixed
sequential replay test. The fixtures use test-only values and contain no live
credentials.

What this result actually proves

The test proves that this dependency-free JavaScript model handles five
sequential copies of the same signed fixture as one intended entitlement
change.

It also demonstrates that four controls solve different problems:

signature verification rejects a body with an invalid signature;
payload allowlisting rejects an authentic but unexpected order;
the event key recognizes a repeated accepted event;
the entitlement key represents the intended access state.

That is the evidence boundary.

What it does not prove

The public example stores processed events in an in-memory Set and
entitlements in an in-memory Map. A process restart clears both.

Its five deliveries run in a normal loop. They do not arrive concurrently. The
example therefore does not prove that two workers cannot pass a database
existence check at the same time.

It also does not prove:

that the custom user ID exists in your database;
atomic rollback after a failure between event recording and entitlement mutation;
behavior across multiple server instances;
refund or revocation ordering;
protection against a late purchase event restoring revoked access.

Those are launch checks for the real database-backed application, not claims
made by this harness.

In production, the “already processed?” check and the entitlement change need
a database-enforced boundary. Use a transaction and appropriate unique
constraints so two overlapping deliveries cannot both win. Resolve the buyer
against a real internal record. Then test forced failures, concurrent delivery,
process restarts, and refund ordering against the deployed database revision.

Do not label the in-memory demonstration production-safe. Do not treat one
green sequential replay as a security certification.

Run the smallest useful test

Start with the test that can fail today:

capture one valid test-mode webhook without exposing its secret;
replay the exact body and signature five times in a safe environment;
inspect processed-event and entitlement state;
save the result with the commit and environment tested.

If five deliveries create five grants, keep that reproduction. It is better
evidence than a vague feeling that retries are “probably handled.”

Inspect the exact test

Run the broader launch-readiness checklist

Sources: Lemon Squeezy webhook requests
and signing requests.