Review security-sensitive tweaks
A tweak is security-sensitive when it changes who can act, what data crosses a request boundary, which files are modified, or what a customer must accept or pay. Review these features as operational changes, even when their interface is only one switch.
Identify the risk category
Give extra review to tweaks that affect:
| Area | What can go wrong |
|---|---|
| Roles, navigation, login, and redirects | A user reaches the wrong destination or loses access to a required control |
| Media and uploads | Files are rewritten, renamed, exposed under a new URL, or no longer recoverable |
| Optimization and cleanup | Records or scheduled work are removed permanently |
| SEO and public text endpoints | Private, draft, excluded, or misleading content becomes publicly discoverable |
| WooCommerce cart and checkout | Prices, eligibility, acceptance, or validation differs between display and server processing |
| Orders, subscriptions, and email | Durable business records or customer communications contain the wrong result |
Presentation changes can also hide controls without removing the underlying WordPress capability. Hiding a menu is not an authorization policy.
Review permissions and request origin
Before production:
- Name the least-privileged role that should use the feature.
- Confirm lower roles and signed-out visitors cannot reach administration actions.
- Test a valid request from the intended screen.
- Test an expired page, duplicate submission, and direct request without the normal screen flow.
- Confirm values are validated for their real type and rendered safely in their destination.
- Check that a public endpoint exposes only content intended for anonymous visitors.
POM Tweaks protects its supported administration actions according to their purpose. For example, media tools are restricted to users allowed to manage uploads or the affected attachment, and settings searches require an authorized administration request. These controls do not replace role design or change approval.
Treat destructive tools separately
Database cleanup and bulk media operations need:
- a recent tested backup;
- staging rehearsal with representative data;
- a named operator and maintenance window;
- a documented dry run when the feature provides one;
- verification of counts, files, references, and customer-facing output;
- a recovery method that does not depend on switching the tweak off.
Do not grant temporary broad administrator access merely to avoid defining the correct operator.
Validate commerce on the server outcome
Visible browser controls are not sufficient evidence for a checkout feature. Complete a real staging transaction and confirm:
- the cart and checkout show the same rule;
- invalid or missing input is rejected;
- totals do not change unexpectedly after refresh;
- the order administration screen preserves the intended evidence;
- emails and subscription or renewal records remain consistent where applicable.
For product-specific terms, test both a product that requires acceptance and one that does not. For price or coupon behavior, test quantities, taxes, shipping, and recalculation rather than trusting the first displayed total.
Approve or reject the change
Enable the tweak in production only when its data owner, affected roles, negative cases, retention impact, and rollback are known. If the feature persists files or records, pair this review with Plan and perform a rollback.