Performance and Security

A WooCommerce page is a WordPress page plus a lot of dynamic state: a product loop is hundreds of database reads, a cart is a per-visitor session, and the checkout is never cacheable. A request is answered by the first layer on the left that holds a valid copy, so performance work is mostly about making the cheap layers answer as often as possible without ever serving one shopper’s data to another. The Core Web Vitals data that the HTTP Archive publishes for sites that run WooCommerce (its September 2026 data, mobile origins) shows where the platform as a whole stands:

Source: HTTP Archive: Core Web Vitals Technology Report

The same dataset puts the median Lighthouse performance score of WooCommerce sites at 0.37 on mobile and 0.565 on desktop. These are fleets of differently hosted stores, not a statement about any one of them, and the comparison page sets them next to the other platforms (Comparison); the useful reading is that the gap is in the server’s first byte, not in the layout. WooCommerce’s own advice for extension authors is a Lighthouse performance score of 90 or above on a simple Woo site, with scripts and styles loaded only on the pages that need them.

Source: WooCommerce docs: Performance best practices

The official guidance is short and strict. Three pages stay dynamic because they show data specific to the current customer: Cart, Checkout and My Account. Database caching must not cache _wc_session_ rows. And WooCommerce sets cookies that tell a cache that a visitor is no longer anonymous:

Source: WooCommerce docs: Configure caching plugins

A real visit confirms the picture. On the test store an anonymous request for the home page sets no cookie at all. The first classic add to cart (/?add-to-cart=11) answered 302 Found and set exactly three: woocommerce_items_in_cart=1, woocommerce_cart_hash=<hash> and wp_woocommerce_session_<hash>=... with Max-Age=172800 (two days) and HttpOnly. From that moment the shopper’s requests must reach PHP. The Store API route of the block checkout works differently (a Cart-Token and a nonce travel in headers, see Store API), but the routes themselves are never cacheable either.

Beyond the three pages and the cookies, a page cache must also bypass: every request that is not GET or HEAD; the query strings add-to-cart, wc-ajax and wc-api (the front end’s AJAX and payment-return endpoints); /wp-json/ (both wc/store/v1, which carries per-shopper data, and wc/v3); and the WordPress back end, login, cron and XML-RPC files. The decision, in the order a cache evaluates it:

Two WooCommerce features exist to make that last box easier. The experimental feature destroy-empty-sessions ("Clear Customer Sessions When Empty", in WooCommerce > Settings > Advanced > Features, off on the test store) removes the session cookie from non-logged-in customers whose session holds no data, so that more anonymous responses carry no cookie; its own description warns that extensions that read the cookie without using session data may break. And the guidance for tracking pixels and consent banners is the same as for any WordPress site: a cookie you do not list in the bypass rule (an analytics cookie such as _ga) must not stop a page from being cached, which is why the rules below match the specific WooCommerce cookies instead of "any cookie".

The VCL in the official page is a fragment, and the longer "troubleshooting" snippet quoted from a forum post uses Varnish 3 syntax, which no longer compiles: Varnish 7.7.3 stops at vcl_fetch with The names 'vcl_*' are reserved for subroutines (the subroutine became vcl_backend_response, req.request became req.method, and the error statement was replaced by synth). The file below is a complete replacement, written for Varnish 7.7 and run in front of the test store. It implements the figure above:

Source: Varnish 7.7 documentation

It was run with docker run -d --network ec-wp -p 18131:80 -v "$PWD/pocket-coffee.vcl:/etc/varnish/default.vcl:ro" varnish:7.7, and the requests below were sent with curl -H 'Host: localhost:8081' (WordPress redirects to its configured address when the host name differs). The X-Cache header that the VCL adds is the observed result:

Source: WooCommerce docs: Configure caching plugins

The cost and the benefit were both measured. A cache miss or a pass took 0.06 to 0.21 s to the first byte; a hit took about 1 ms. With k6 (5 virtual users for 10 seconds against /product/pocket-mug/, from a container on the same Docker network), the page straight from Apache and PHP delivered 361 requests (35.7 requests per second, average 139 ms, 95th percentile 186 ms), and the same page through Varnish delivered 75,473 requests (7,547 per second, average 0.6 ms, 95th percentile 0.8 ms), with no failed request in either run. That is a factor of about 200 for anonymous traffic on this hardware, which is the reason every serious WooCommerce deployment has a page cache, and the reason its exclusions have to be right.

Things that still need decisions in production: the TTL (10 minutes here) against the freshness of prices and stock; purging when a product changes (a plugin or a hook on woocommerce_update_product and woocommerce_product_set_stock can send a PURGE or a ban for the product URL and its archives); HTTPS termination in front of Varnish (Varnish itself speaks plain HTTP; terminate TLS with the web server, HAProxy or the CDN and forward X-Forwarded-Proto); and what to do with query strings such as utm_* (the test configuration caches each distinct URL separately, so a campaign multiplies cache entries unless the tracking parameters are stripped in vcl_recv).

On Nginx the same policy is written as map blocks and applied with fastcgi_cache_bypass (do not answer from the cache) and fastcgi_no_cache (do not store). The maps below produce a single flag per request. The final map exists because those two directives treat any value except an empty string and 0 as true: concatenating three flags that are all 0 gives 000, which would bypass the cache for every request.

Source: nginx documentation: ngx_http_map_module

The server block that uses them with PHP-FPM (checked with nginx -t on nginx 1.30; there is no FPM behind it in the test stack, so the cache behaviour was tested with the same maps on proxy_cache, below):

Source: nginx documentation: ngx_http_fastcgi_module

With proxy_cache, the same maps in front of the test store gave: / and the product page MISS then HIT; /cart/, /my-account/, /checkout/, /?add-to-cart=11, /?wc-ajax=get_refreshed_fragments and /wp-json/wc/store/v1/products BYPASS; a request with woocommerce_items_in_cart, wp_woocommerce_session_ or wordpress_logged_in_ BYPASS; a request with only _ga HIT. The important detail in the location for the uploads folders is the second pitfall of the page: WooCommerce protects uploads/woocommerce_uploads/ (downloadable products and the Analytics exports) and uploads/wc-logs/ with a .htaccess that says deny from all. The test store returned 403 for both directories. Nginx ignores .htaccess, so on Nginx the protection silently disappears unless the location above (or an equivalent) is added; log files and customer CSV exports are exactly what scanners look for.

Plugin-based caches follow the same rules, and the official page has per-plugin notes: add mfunc to the "Ignored comment stems" in the W3 Total Cache minify settings; keep Cart, Checkout and My Account out of WP Rocket’s cache and avoid JavaScript minification; WP Super Cache is natively compatible because WooCommerce tells it not to cache Cart, Checkout and My Account. A symptom of a cached My Account page, also listed there, is a password reset that returns to the login form in a loop. The WordPress constant that makes a drop-in page cache work is WP_CACHE, which only asks WordPress to load wp-content/advanced-cache.php; setting it does not cache anything by itself.

Source: WordPress developer docs: Cache

"Cart fragments" is the mechanism of the classic mini cart. The script wc-cart-fragments (depends on jQuery and js-cookie) posts to /?wc-ajax=get_refreshed_fragments when a page loads and after every add to cart, receives a map of CSS selector to HTML, replaces the matching elements, and keeps the fragments in sessionStorage and the cart hash in sessionStorage and localStorage (the keys are derived from the site address and the theme so that two stores on one domain do not collide; the filters woocommerce_cart_hash_key and woocommerce_cart_fragment_name change them). The request has a five second timeout. It exists because the page that contains the mini cart may come from a cache and cannot know the cart; the cost is one uncached PHP request on every page view of every visitor who has the script, which defeats a good part of the page cache. Two facts bring it back under control:

The endpoint itself answers a POST with the fragments and cart_hash; on the test store the empty cart returned the empty-cart message and an empty hash. A classic theme that still shows a mini cart in its header can add its own fragments with the filter woocommerce_add_to_cart_fragments (the keys are selectors) and, if it does not need the script on some pages, remove it there:

Source: WooCommerce docs: Optimize store performance

The code is in the pocket-coffee-perfsec plugin, passed PHPCS (WooCommerce-Core), and was exercised over HTTP: with a cart (the cookie jar of a /?add-to-cart=11 request) the POST to /?wc-ajax=get_refreshed_fragments returned the fragment keys div.widget_shopping_cart_content and span.pc-cart-count, the latter as <span class="pc-cart-count">1</span> with a non-empty cart_hash; without a cart the badge read 0 and the hash was empty. Enqueuing the script and then running the wp_enqueue_scripts action with the plugin active left it dequeued. The classic-theme caveat is real: removing the script from a page that shows a legacy mini cart freezes that cart until the next full reload, so test every template before shipping a dequeue.

WooCommerce 11.2.1 lists these performance-related features in WooCommerce > Settings > Advanced > Features (the identifiers are those of FeaturesController, and each is stored in an option named woocommerce_feature_{id}_enabled):

Source: WooCommerce docs: Optimize store performance

The product cache is the one change that is on by default for new stores and needs no tuning; the others should be switched on one at a time, in staging, with the extensions the store really uses, because each changes how third-party code sees sessions, emails or order objects. Check the state with wp eval 'var_dump( Automattic\WooCommerce\Utilities\FeaturesUtil::feature_is_enabled( "product_instance_caching" ) );' or wp option get woocommerce_feature_product_instance_caching_enabled (the option read yes on the test store).

Without a persistent object cache, WordPress keeps its caches in PHP memory for one request and writes transients to wp_options. The test store has no external object cache (wp_using_ext_object_cache() is false, wp cache type prints Default) and its options table shows the consequence: 246 transient rows of about 946 KB in total, all with autoload off. A drop-in object-cache.php backed by Valkey or Redis moves those to memory, shares them between PHP workers and makes the order and meta caches useful across requests. Use a key prefix that is unique per site if the cache server is shared, and size it with an eviction policy that cannot evict keys without a time to live from under an application that expects them.

Autoloaded options are read on every request, so their total size matters. On the test store (WordPress 6.6 and later store the autoload flag as on, off, auto, auto-on or auto-off):

Source: WordPress developer docs: Optimization

returned 327 autoloaded options and about 73 KB (on 224 rows and 67.6 KB, auto 103 rows and 5.6 KB), the largest being _transient_wp_core_block_css_files (23,778 bytes) and rewrite_rules (18,070 bytes); the 313 options with autoload off held 896 KB. A store that has run for years often shows megabytes here, usually left by uninstalled plugins; the query above is the first thing to run on a slow store.

Sessions are rows in woocommerce_sessions: the cookie lasts two days, and in the session handler of 11.2.1 the defaults are one day for "expiring" (the point after which a request refreshes the session) and two days for "expiration" for a guest, or one week for a logged-in customer (the filters wc_session_expiring and wc_session_expiration; the code logs a warning about the table size when sessions are kept for much longer). A recurring Action Scheduler action, woocommerce_cleanup_sessions, runs every 12 hours; the tools clear_sessions and clear_transients (WooCommerce > Status > Tools, wp wc tool run <id> --user=<admin>) empty them by hand. A bot that crawls add-to-cart links can create sessions faster than the cleanup removes them, which is another reason to rate limit and to block add-to-cart URLs for crawlers in robots.txt.

WooCommerce 11.2.1 contains about 3,700 PHP files (3,664 on the test store); the whole web root of the test store, with WordPress core, WooCommerce, the mcp-adapter and akismet plugins and about twenty small test plugins, has 5,667. OPcache keeps the compiled scripts in shared memory; if it is too small or has too few slots, PHP recompiles files on every request. The official WordPress Docker image ships these values, which the test store read back with php -i:

Source: PHP manual: OPcache configuration

A configuration for a production server with WooCommerce and a few dozen plugins, checked by loading it into php:8.3-cli and reading the values back:

Source: WooCommerce documentation: Server recommendations

The values the merchant documentation states are a WordPress memory limit of 256 MB, PHP 8.3 or later recommended, and HTTPS. With validate_timestamps=0 the web server keeps running the old code after a deployment until OPcache is reset (reload PHP-FPM, or call opcache_reset() from a deployment step), which is the price of the saving. PHP-FPM replaces Apache’s mod_php on most tuned servers; its pool file decides how many requests run at once:

Source: PHP manual: FPM configuration

php-fpm -t accepted the file in php:8.3-fpm-alpine (the message is configuration file /usr/local/etc/php-fpm.conf test is successful). The max_children rule is the one that prevents the classic outage: more simultaneous checkouts than workers queue up, and a pool larger than memory allows swaps the server to a halt. The PHP requirements move: the 11.2.1 plugin header says PHP 7.4, the merchant page recommends 8.3 or later, PHP 8.1 becomes the minimum in 11.6 (planned for February 2027), and the WooCommerce developer blog of 2026-10-21 says the October 2026 PHP security release will not be backported to any version before PHP 8.2, so an older PHP is an unpatched PHP (see Versions, requirements and release cadence). For the deeper PHP side see OPcache, JIT and performance.

Source: WooCommerce developer blog: PHP security release

Apache or Nginx should compress text, serve images and scripts with a long lifetime (WordPress adds ?ver= to enqueued files, so a new version is a new URL), and speak HTTP/2 or HTTP/3 over TLS. The official Docker image had gzip for CSS (Content-Encoding: gzip) but sent no Cache-Control or Expires for static files. The .htaccess below, run on Apache 2.4 with mod_expires, mod_headers and mod_deflate in a throw-away container, produced Cache-Control: public, max-age=31536000, immutable with a one-year Expires and Content-Encoding: gzip for a CSS file, and Cache-Control: max-age=0 for the HTML page:

Source: WordPress developer docs: Optimization

On Apache, the choice of MPM matters: the image uses mpm_prefork (one process per request, required by mod_php), while PHP-FPM allows the event MPM and far more concurrent connections for the same memory. Images are the other large item of a product page: upload WebP or AVIF where the browsers of your customers support them, generate the sizes WooCommerce registers (the thumbnail regeneration job appears in WP-Cron as wp_1_wc_regenerate_images_cron on the test store), lazy-load below-the-fold images, and put a CDN in front of wp-content/uploads and the theme assets. A CDN in front of the whole site is a page cache and must follow the same bypass rules above. The old books recommend "enable HTTPS only on checkout" (WooCommerce Cookbook): that advice is obsolete, because HTTPS everywhere is now a requirement of browsers and of HTTP/2, and the FORCE_SSL_ADMIN constant below covers the back end.

MariaDB or MySQL spend most of their time on the same few things: reading wp_options, wp_postmeta and the order tables. Three settings and one habit help.

On several web nodes the same tuning moves to a managed database, a shared object cache and a CDN; the layout is in Cloud: Database, HPOS and Sessions and Cloud: Caching, CDN and Checkout.

WordPress runs its scheduled events when a page is requested, which on a cached store may be rarely, and Action Scheduler piggybacks on that to run its queue every minute (the test store has the hook action_scheduler_run_queue with a one-minute recurrence). For a store with orders, replace the visitor-triggered cron with a real one: set define( 'DISABLE_WP_CRON', true ); in wp-config.php and run wp cron event run --due-now from the system cron every minute (a longer interval delays emails and Analytics imports). The WordPress documentation states the constant and WP_CRON_LOCK_TIMEOUT, which stops a second cron process from overlapping.

Source: WordPress developer docs: Editing wp-config.php

Measure before and after each change, with the tool that matches the question: Lighthouse (the benchmark the official advice cites) and PageSpeed Insights for the page as a visitor sees it; Query Monitor on staging for queries, hooks and HTTP calls per request; the slow log of PHP-FPM and MariaDB for the server; a load tool such as k6 for throughput (the numbers above) with a scenario that mixes cached pages and the cart, because an add-to-cart flow behind a page cache is the case that breaks; and the Core Web Vitals report of the Search Console for the field data of real visitors. WooCommerce’s performance advice also says to test the store with and without your extension, and to load scripts and styles only where they are needed.

WooCommerce is open source software that a merchant installs and updates. Automattic’s WooCommerce team writes and patches the plugin and receives vulnerability reports through its HackerOne programme; WordPress core has its own security team and release process; every extension, theme and custom snippet has its own author, its own update channel and its own risk; the host owns the operating system, the web server, TLS and backups; and the merchant owns passwords, user roles, the choice of extensions and how fast updates are applied. Most real compromises of WooCommerce stores happen in the layers around the plugin: an outdated extension, a weak administrator password, a file that should not have been public. The history below shows what the core team has had to fix, and the policy after it shows how long a fix stays available.

The record, with the NVD base score (CVSS 3.1) and the versions the advisories name. The "fixed in" column is what the advisory or the release notes say; check the current advisory before relying on a version number.

Source: NVD: CVE-2021-32789, NVD: CVE-2021-32790, NVD: CVE-2023-28121 and Wordfence: Massive targeted exploit campaign against WooCommerce Payments underway (July 2023)

The July 2021 incident is the one that shaped the update model. WooCommerce identified the flaw on 2021-07-13, reported by a researcher through the HackerOne programme, audited the code, built patches for every affected branch ("90+ releases") and started deploying them automatically: WordPress.org pushed a forced update to vulnerable stores from 2021-07-14, which WP Tavern called "a practice that is rarely employed". The forced update stopped when 5.5.2 shipped on 2021-07-23 (its own changes were unrelated). The vendor’s advice afterwards is a model of an incident checklist: update to the highest version of your branch, change the passwords of administrators (especially reused ones), rotate payment gateway credentials and WooCommerce API keys, and check access logs, because there is no definitive way to confirm that a site was exploited. Sites that did not receive the update had automatic updates disabled, a read-only file system, a conflicting extension, or a version below the affected range. The vendor called the Blocks flaw critical; NVD scores it 7.5, which is the number in the table.

Source: WooCommerce: Critical vulnerability detected, July 2021

WooCommerce 11.2.0 (2026-10-07) is another release with security fixes: its release notes say to update all stores to 11.2, and name items such as Cc and Bcc recipients on password-reset-type emails, the authorisation of downloads and a multisite administrator item. 11.2.1 followed two days later with two checkout regression fixes. The pattern across five years is consistent: reports arrive through HackerOne, core fixes ship as point releases on several branches, and the severity is moderate to high rather than catastrophic; the catastrophic entries are in the plugin ecosystem.

Source: WooCommerce developer blog: WooCommerce 11.2.0 release notes

The WordPress.org directory lists 10,039 plugins tagged woocommerce and WooCommerce itself has more than 470 million downloads and at least 7 million active installations (the directory reports installations in bands), so the extension catalogue is as large as the core. The figure shows what that does to the vulnerability record. Core entries are a handful per year; the entries whose text merely mentions WooCommerce, nearly all of them in third-party plugins and themes, grew from 87 in 2022 to 271 in 2023, 650 in 2024, 709 in 2025 and 893 in 2026 by 27 October. The count includes every plugin that says "WooCommerce" in its description, so it is an upper bound on the WooCommerce-specific risk, and part of the growth is better disclosure and more researchers rather than worse code. The independent view agrees on where the problems are: Patchstack’s report on 2025 attributes 91% of the new vulnerabilities in the WordPress ecosystem to plugins and 9% to themes, with 6 vulnerabilities in WordPress core. It is a third-party company’s analysis of the WordPress ecosystem as a whole, not of WooCommerce, and the shares are for that report’s year.

Source: Patchstack: State of WordPress security in 2026

What this means for a store: choose extensions the way you choose a payment provider. Prefer extensions that are maintained (a recent release, a tested-up-to header that is at least the previous WordPress series, a changelog that mentions security), that pass WooCommerce’s own checks for the Marketplace (QIT security and malware tests, see Testing, deployment and Marketplace), and that declare compatibility with HPOS and the checkout blocks; remove what you do not use (an inactive plugin’s files can still be attacked); never use "nulled" copies of paid plugins, which are a common way to install a back door; and keep the count small. Bundled libraries are a hidden dependency: Action Scheduler is bundled by WooCommerce and by many other plugins, and WordPress loads the highest registered version of it (the version registry is in ActionScheduler_Versions), so a store’s behaviour depends on the newest copy any plugin ships.

The security patch policy of WooCommerce is published and mechanical. When a security fix warrants it (CVSS 9 or higher), patches are provided for the last 21 major versions, where "major version" means the x.y number (10.8, 10.9, 11.0), not semantic versioning; otherwise the fix is published for the latest version only. The window is rolling: it moves up by one with every release.

Source: WooCommerce docs: Security patch support policy

At the release cadence of about five weeks, 21 versions are roughly two years. Three cautions: lower-severity fixes (such as CVE-2025-15033 above) may still be backported, but only the latest version is promised them; courtesy backports outside the policy are possible for some critical classes; and the policy is about WooCommerce, not about the extensions or WordPress itself, which have their own support rules. The release process is the other half of the picture: a minor release about every five weeks (feature freeze, beta 1, beta 2, release candidate, final), with point releases for fixes; the observed release dates from 10.0.0 on 2025-07-07 to 11.2.0 on 2026-10-07 are 13 releases in 15 months. Plugin and Marketplace headers follow the L-1 policy: WooCommerce supports the latest and the previous series of WordPress and WooCommerce, and only the latest patch release of each series.

Source: WooCommerce docs: Version support policy

Practical rules that follow: stay on the latest stable and apply point releases within days; if you must stay behind, stay inside the 21-version window and watch the security notices; put every site you run on the same schedule. A scripted way to see where a store stands (all read-only, run on the test store):

Source: WordPress developer docs: Hardening WordPress

The checksum commands compare files with the copies WordPress.org publishes: wp plugin verify-checksums woocommerce answered Success: Verified 1 of 1 plugins. and wp core verify-checksums listed Warning: File should not exist: wp-config-docker.php (a file the Docker image adds) and then Success: WordPress installation verifies against checksums. The last command printed disabled for WooCommerce: plugin auto-updates are off by default in WordPress. Turning them on (wp plugin auto-updates enable woocommerce) trades the risk of a bad update for the risk of a late one; for a small store without a staging pipeline the second risk is larger, and for a store with one the answer is to test the update the day it is released and ship it the day after. WordPress core updates automatically for minor releases by default (WP_AUTO_UPDATE_CORE is minor by default). Keep PHP in the supported range: an old PHP does not get security fixes whatever the plugin does.

Vulnerabilities in WooCommerce must be reported privately through Automattic’s HackerOne programme (https://hackerone.com/automattic/), never in a public GitHub issue. For an extension from another vendor, use the security contact that the vendor publishes. The 2021 flaw was found and reported through the programme.

Source: WooCommerce docs: Security patch support policy

The official security guide for developers and merchants is a checklist: keep WordPress, WooCommerce and every plugin up to date; install plugins and themes from reputable sources and remove the unused ones; use strong unique passwords, limit login attempts and add two-factor authentication; disable XML-RPC and restrict the REST API where it is not needed (WooCommerce’s own Store API, blocks and admin screens use the REST API, so restrict routes, do not switch it off); keep file permissions tight; use HTTPS; back up off-site; and monitor. It also names two code-level standards for extensions: PHPCS with the WordPress and WooCommerce rulesets, and Semgrep, with no failures against either. The list below turns that into checks that were run on the test store, which is a default Docker installation and therefore a fair picture of an untouched one.

Source: WooCommerce docs: Security best practices

Source: WordPress developer docs: Hardening WordPress

The matching wp-config.php lines, all documented constants of WordPress core (they were not applied to the shared test store; the file was checked with php -l and the behaviour is the documented one):

Source: WordPress developer docs: Editing wp-config.php

For the accounts: give each person their own user, with the Shop manager role rather than Administrator for staff who handle orders; use two-factor authentication from a plugin or from the single sign-on of the host; and treat Application Passwords (used by the REST API and by the MCP adapter, see AI and MCP) as credentials of the user who created them, with that user’s permissions. A web application firewall in front of the store (from the host, a CDN or a plugin) filters the commonest attacks; it supplements patching and does not replace it.

The same rules apply to the custom code of a store, and the shortcodes and form handlers written for one are where the reports come from. The Pocket Coffee roast lookup below is a shortcode that lists the beans of an origin and an admin form handler that stores a roast date. The first version is how the book recipes write it; the second adds the five habits of WordPress security: sanitise input, prepare SQL, escape output, check a nonce and a capability, validate the value, and redirect safely.

Source: WordPress developer docs: Security

Running PHPCS with the WordPress-Extra standard on it (PHP_CodeSniffer 3.13.6, WPCS 3.4.1) reported four errors and two warnings, in the report’s words: Processing form data without nonce verification (on both $_GET and $_POST), Use placeholders and $wpdb->prepare(); found interpolated variable $origin, and wp_redirect() found. Using wp_safe_redirect(), along with the "allowed_redirect_hosts" filter if needed, can help avoid any chances of malicious redirects. It did not report the missing esc_html() on the returned markup or the missing capability check, which is the reason the standard is a floor and code review still matters. Run as a function with ?origin=<script>alert(1)</script>, the unsafe version returned <h3>Beans from <script>alert(1)</script></h3><ul></ul>: the script reaches the page. The safe version:

Source: WordPress developer docs: Security

The safe file passes PHPCS with one warning (Found unknown capability "edit_product": the sniff does not know WooCommerce’s meta capability; current_user_can( 'edit_product', 10 ) is true for the administrator on the test store). Running it: ?origin=<script>alert(1)</script> sanitises to an empty string and returns nothing (an empty origin returns an empty string on purpose, because LIKE '%%' would list every product); Mug<b> is cut to Mug and lists the two mugs with every title escaped; x' OR 1=1 -- is escaped to x' OR 1=1 -- and returns no row; and a logged-in POST /wp-admin/admin-post.php for pc_set_roast_date with no nonce answered 403. Product data is saved through the CRUD object (wc_get_product(), update_meta_data(), save()), not update_post_meta(), so that the code keeps working with HPOS and with the product caches (see CRUD objects and data stores).

The books on running a shop (Sims is the most thorough) treat security as certificates, PCI compliance and maintenance, and the substance still holds. Use HTTPS on every page, not only the checkout. Keep card data off your server: use a gateway whose card fields are served by the provider (hosted fields, an iframe or a redirect), so the store never sees a card number, which also keeps the store’s PCI scope small; the Checkout block integrations in Payment gateways are built for that. Do not store anything you do not need, and know what you store: orders contain names, addresses and emails. The compliance questions of a specific country and card scheme belong with the payment provider and a lawyer; this page cannot answer them.

The routine below is generic advice from the books, checked against what the platform now provides.

Source: WooCommerce docs: Security best practices

Backups of an HPOS store include the wc_orders tables; with HPOS authoritative and synchronisation off, the wp_posts rows of orders are only placeholders, so a restore that brings back only the posts tables loses the orders (see HPOS).