// TECHNOLOGIES / STRIPE

Stripe

Stripe, from the customer's seat.

Stripe's own infrastructure is not the risk — your integration is. The Dashboard shows the keys you created and the webhook endpoints you registered; it cannot show you that a sk_live_ key was compiled into your JavaScript bundle, that stripe.json is being served from your web root, or that your webhook receiver's source is public and never checks a signature. NewScan proves those from the outside — and treats your pk_live_ publishable key, which is meant to be public, as metadata rather than a finding.

▸ Run the free scan ← All technologies

The dashboard blind-spot

// why an external scan matters

// THE DASHBOARD SHOWS (WHAT YOU CONFIGURED)

The keys you created, the webhook endpoints you registered, their delivery history, and your Radar rules — all as you configured them in the Dashboard.

// IT CAN'T SEE (NEWSCAN DOES)

That a live secret or whsec_ signing key is readable in your deployed bundle, that a server config reached the web root, that your webhook handler's own source is downloadable — and, from its structure, that it never verifies Stripe-Signature before acting on an event.

What NewScan records

// proven, then reproduced

Secret key in client-side code

CRITICAL

A sk_live_, rk_live_ or whsec_ value found in the deployed browser bundle. Possession is the finding: the value is redacted in the report and is never used to call Stripe.

Integration config exposed

HIGH

A Stripe config served anonymously from the web root with real secret material beside Stripe context. A config holding nothing but a publishable key is correct, and stays silent.

Webhook receiver source readable

HIGH

The handler's own source served with a 200, plus either an unredacted secret or the structural proof that verification is absent — it dispatches on Stripe event types yet never references constructEvent or the signature header.

Connect redirect_uri not validated

HIGH

Your own Connect authorization endpoint issues a code to an unregistered redirect URI, proved by a real redirect carrying the code to a canary host.

What is never flagged

// the false-positive contract

A scanner earns its place by what it stays quiet about. These are guarantees, each one asserted by a test that fails the build if it regresses — not best-effort tuning.

pk_live_ / pk_test_ publishable keys

Public by design. They belong in your client code and are fingerprint evidence only — never a finding, alone or beside anything else.

ca_ Connect client ids

Public integration metadata, exactly like the publishable key.

A fabricated webhook event

Never sent. A real receiver can queue or mutate state before rejecting a forged event, so a 200 to a fake one is not evidence — and manufacturing it could move real data.

Any payment, customer, refund or key-validation call

Out of scope, permanently. A discovered key is never used against Stripe.

How it's proved

// training/tech/stripe

A Stripe-integrated app and a safe twin that ships the identical publishable key and Connect client id. The twin must score zero — that negative is the harder half of the measurement.

// FINGERPRINT FIRST

The check is silent unless the product is confirmed by two independent signals. A single, spoofable marker confirms nothing.

// REPRODUCE BEFORE RECORD

Every finding is re-run by our own detector before it is written down. A model's self-assessment is discarded, not merged.

// SEVERITY THAT MAPS

One calibrated severity per finding, translated into PCI DSS, SOC 2, ISO 27001, HITRUST, HIPAA and NIST 800-53 ratings with remediation SLAs.

Run it against your own Stripe

NewScan is free and self-hosted — bring your own key. Every check on this page runs in the deterministic floor with no model and no provider key at all, so scanning your own Stripe surface is local to you and depends on no hosted resource.

Get NewScan (FREE) → Talk through your results