Stripe Integration Audit

Why it matters: The secret key can create charges, issue refunds, and modify billing — far more access than analytics needs. A restricted read-only key limits exposure if the key is ever leaked.

Impact: A leaked key creates far greater potential damage than necessary for the use case.

How to fix: Create a restricted API key in Stripe with only read permissions on the resources analytics actually needs.

Manual

Why it matters: Keys can leak through old logs, committed code, or former employee access without anyone noticing. Periodic rotation limits how long a leaked key stays valid.

Impact: An old, unrotated key that has leaked at some point remains exploitable indefinitely.

How to fix: Rotate API keys on a regular schedule (e.g. every 90 days) and immediately after any suspected exposure.

Manual

Why it matters: Hardcoded secrets end up in version control history permanently, visible to anyone with repository access, even after being removed from the current version.

Impact: Any key committed to source control should be considered compromised indefinitely.

How to fix: Move all API keys to environment variables or a dedicated secrets manager, and rotate any key that was ever hardcoded.

Manual

Why it matters: Without signature verification, your endpoint will process any POST request that hits the URL, not just genuine events from Stripe — including forged requests from anyone who discovers the endpoint.

Impact: An attacker could send fabricated events (e.g. a fake successful payment) that your system would process as real.

How to fix: Verify the stripe-signature header on every webhook request using your webhook signing secret before processing.

Automated by Dnoise

Why it matters: A transient failure (a brief database outage, a deploy in progress) shouldn't mean permanently losing that event's data.

Impact: Silent data gaps in billing records whenever webhook processing has a bad moment.

How to fix: Queue failed webhook processing for retry rather than discarding it on first failure.

Automated by Dnoise

Why it matters: Without idempotency keys, a network retry after a timeout can accidentally create a duplicate charge or subscription, because Stripe has no way to know the retry is the same request.

Impact: Risk of duplicate charges or subscriptions under network instability.

How to fix: Pass a unique idempotency key on every state-changing Stripe API call.

Manual

Why it matters: If your endpoint is down for any period, Stripe will retry for a while but eventually stop — after that, missed events are gone unless you can pull and replay them manually.

Impact: Permanent data gaps for any outage that outlasts Stripe's retry window.

How to fix: Build a way to fetch and replay events from Stripe's event log for a given time range after downtime.

Manual

Why it matters: Silent failures mean billing data can quietly drift out of sync with Stripe with no alert to anyone.

Impact: Data quality issues go undetected until they show up as a confusing discrepancy much later.

How to fix: Log every webhook processing error with enough context (event ID, error, timestamp) to investigate.

Automated by Dnoise

Why it matters: Logs that no one is watching are only useful after the fact. An active alert catches a systemic issue (a bad deploy, an expired credential) within minutes instead of days.

Impact: Extended periods of silent data corruption before anyone notices.

How to fix: Set a threshold-based alert on webhook error rate that notifies the team in real time.

Manual