Skip to content

Security · WordPress

I found an API key in my page source in WordPress

The value is served to everyone who views source. Treat it as compromised and rotate it at the provider before fixing how it got there. A build-time prefix such as `NEXT_PUBLIC_` or `VITE_` inlines whatever it is given, which is the usual way this happens. A live sandbox key is the quieter version: the payment form accepts test cards and declines real ones, and nothing is logged as a failure.

The fix for WordPress

13x detects your framework from the response and hands you this version rather than the generic one — below 50% confidence it hedges and gives you the generic one instead.

Rotate the key first — revoke and reissue it in the provider's dashboard.

A key visible in page source on WordPress almost always comes from one of three places:

1. A plugin settings field that renders into the page. Check the plugin's settings for a "publishable"/"secret" pair that has been filled in the wrong order — this is the most common cause by a wide margin. 2. A theme file. Search your theme for the key shape: grep -rE "sk_(live|test)_|AKIA[0-9A-Z]{16}" wp-content/themes/ 3. A hardcoded value in `functions.php` or a custom block.

Move it into wp-config.php, which is outside the web root's served output:

php code
define( 'STRIPE_SECRET_KEY', 'sk_live_REPLACE_WITH_YOUR_KEY' );

Then read it server-side with STRIPE_SECRET_KEY and never echo it into a template, an inline script, or a wp_localize_script payload — that function writes its data straight into the HTML.

On a different stack? The general version of this fix explains what 13x checks and why it matters, without assuming a framework.

Check your WordPress site

113 deterministic checks against your live URL, in about 30 seconds. Framework detected from the response, so every fix comes back in the form your stack actually uses.

No signup. Results in 30 seconds.

The same fix, other stacks