Security and performance

Shoppers trust a store with their card and their account; the storefront and the Companion plugin are built to earn that trust by default. Most of what this page describes needs no setup. The rest is a secret or a key set once, in the right place.

Where it shows

Every page, with extra protection on checkout, order confirmation, cart and account

Configure in

Mostly automatic; Turnstile under StoreFront › Settings › Authentication › Turnstile; shared secret in both deployments

Requires

STOREFRONT_SHARED_SECRET on the storefront and RSC_STOREFRONT_SHARED_SECRET in wp-config.php for per-Shopper limits

Try it in Demo Mode

Payment-page headers and decline handling behave the same in Demo Mode

What shoppers get

• Card details entered only into the payment company’s own fields, on a page no other script can tamper with.
• Accounts that stay signed in safely, and sign out everywhere if something looks wrong.
• Forms protected from spam without puzzles to solve.
• Pages that load quickly, with images sized and compressed for each screen.

Payment pages

The checkout and order confirmation pages are the storefront’s payment pages, and they run only the scripts the storefront chooses:

• A strict Content Security Policy with a fresh nonce on every request. Only the storefront’s own code and the payment SDKs it loads (Stripe.js and PayPal) may run, and only Stripe and PayPal may be framed.
• No custom scripts. Tags pasted into wp-admin, such as analytics or chat widgets, never load on these pages, and arriving at checkout is always a full page load, so a tag from an earlier page can’t follow the Shopper in.
• No framing. Checkout, order confirmation, cart and account pages refuse to be embedded in another site, which blocks clickjacking. The order confirmation address, which carries the order key, is never passed on as a referrer.
• Declines that don’t explain. When a card is declined, the Shopper sees a generic message, not the bank’s reason. That tells a card tester nothing; your team still finds the real reason in the order notes and the payment plugin’s log.

Payment keys stay in WordPress, never in the storefront’s environment. See Payments architecture.

Shopper identity and abuse limits

Every request to WordPress comes from the storefront’s server, so on its own WordPress would see one address for every Shopper. With a shared secret set on both sides, the storefront signs each Shopper’s real address, and the Companion plugin trusts it only when the signature checks out. That turns on fair limits per Shopper: checkout attempts, PayPal order preparation and order lookups are rate limited, which slows card testing without throttling the whole store as one client.

Further limits apply per email address or per network address to newsletter sign-ups, stock alerts, the contact form, social sign-in, resent verification emails, and guest review uploads, replies and reports.

Sessions

• Tokens never reach the browser’s JavaScript. The storefront keeps the Shopper’s sign-in tokens in an encrypted, http-only session cookie.
• Short-lived access, rotating refresh. Access tokens from the Companion plugin last minutes; refresh tokens are replaced on every use. If an old refresh token is ever replayed, every session for that account is signed out and the customer is emailed a security alert.
• Remember me. A remembered sign-in lasts up to 30 days; otherwise the session ends after a day.
• Instant revocation. Signing out everywhere, resetting or changing a password ends existing sessions.

Bot protection

Cloudflare Turnstile guards reviews, guest review replies, the contact form and guest stock-alert sign-ups, with a switch per form. It works without CAPTCHA puzzles, and the Companion plugin doesn’t send the Shopper’s address to Cloudflare. Turnstile keys, like social sign-in credentials, are set in WordPress, not in the storefront’s environment. See Sign-in and security.

Performance

• Server-rendered by default. Pages are React Server Components, with small interactive islands, so Shoppers download little JavaScript.
• Optimised images. Product and media images are resized for each screen and served as AVIF or WebP where the browser supports it, and load lazily below the fold.
• Self-hosted fonts, with no third-party font requests.
• Only what’s shown is fetched. Home-page sections a deployment leaves out cost no backend requests, and the brand directory and filter counts are computed on the backend rather than product by product.
• Cache-friendly backend. The Companion plugin’s public settings and content are served with five-minute cache headers, and the storefront re-reads them on the same schedule. With the free WP REST Cache plugin installed, catalogue reads are cached too and cleared automatically when stock, prices, reviews or settings change. Cart, checkout, payment and signed-in requests are never cached.
• Edge or Node. Deploy to Cloudflare Workers through OpenNext, or to any Node host. See Deployment.

Set it up

1. Generate one shared secret and set it as STOREFRONT_SHARED_SECRET on the storefront and RSC_STOREFRONT_SHARED_SECRET in wp-config.php. Make sure your proxy passes X-Forwarded-For. See wp-config constants.
2. Add Turnstile keys and switch it on under StoreFront › Settings › Authentication › Turnstile.
3. Optionally install WP REST Cache on WordPress.
4. Work through the Go-live checklist.

Add a limit on sign-in

The sign-in, registration, forgot-password, reset-password and change-password routes have no built-in attempt limit yet. Before launch, add a rate-limiting rule for them at your CDN or web application firewall.

Good to know

• Without the shared secret, the per-Shopper checkout limit stays off and other address-based limits count the whole store as one client. The Companion plugin warns administrators while it is missing.
• Settings take up to about five minutes to reach Shoppers because of the cache headers.
• No page cache yet. Pages are rendered on each request; incremental page caching is on the roadmap.
• Hiding decline reasons applies store-wide, including WordPress’s own block checkout if you still use it.

Related

Checkout and paymentsDouble-charge protection and lost-payment recovery.

Sign-in and securityTurnstile, social sign-in, sessions and API access.

DeploymentCloudflare Workers or a Node host.

Payments architectureHow embedded payments are kept safe.