WordPress Security Hardening Checklist for Custom Code Sites

Overview

A basic WordPress install can often be secured with a handful of platform-level settings, but custom code changes the risk profile. The moment you add custom templates, AJAX handlers, REST endpoints, shortcode logic, admin pages, or snippet-based changes in functions.php, you introduce more places where mistakes can happen. Most problems are not dramatic zero-day events. They are ordinary issues such as weak admin access, unsafe file editing, poor input validation, forgotten staging sites, exposed debug logs, or outdated custom plugins that no longer match current WordPress behavior.

This WordPress security hardening checklist is built around that reality. It is meant to be reused, not skimmed once. The core idea is simple: secure the environment first, then secure the code paths, then secure the workflow that moves changes from local to staging to production.

Before you start, keep three assumptions in mind:

• Custom code increases maintenance responsibility. A child theme or plugin customization is not done forever after it works once.
• Security and stability are connected. A site that is easy to debug, roll back, and audit is also easier to keep secure.
• Hardening is layered. No single plugin or setting replaces careful permissions, safer coding patterns, and a clean deployment process.

If you are still improving your local workflow, it helps to pair this checklist with a dedicated local WordPress development setup guide and a clear WordPress Git workflow. Security gets much easier when changes are versioned and tested before they go live.

Checklist by scenario

Use the scenario that best matches the kind of customization you maintain. Many sites will need more than one list.

1. Baseline hardening for every custom WordPress site

• Keep WordPress core, themes, and plugins updated. This includes custom plugins and child themes. If you maintain your own code, review it after core updates rather than assuming older patterns still behave safely.
• Remove inactive themes and plugins you do not need. Deactivated code can still create risk if it remains installed and forgotten.
• Use strong unique passwords and two-factor authentication where possible. Especially for administrator, hosting, DNS, and database-related accounts.
• Limit administrator accounts. Give users the lowest role that still lets them do their work.
• Disable file editing in the admin area. Direct editing of theme and plugin files in production creates both security and recovery problems.
• Use HTTPS everywhere. Do not leave mixed development habits in production for logins, admin sessions, or form submissions.
• Turn off public indexing for staging sites. Staging copies with real data are often less protected than production.
• Make backups routine and test restore procedures. A backup you have never restored is not yet a recovery plan.

2. Checklist for child themes and theme customization

• Keep customizations in a child theme or controlled custom plugin. Avoid editing a parent theme directly unless you fully own the update path.
• Audit template overrides. Check copied template files against current parent theme versions so you are not preserving outdated markup or behavior.
• Escape output in templates. Any data printed into HTML, attributes, URLs, or inline scripts should be escaped for its context.
• Sanitize and validate input. Search forms, customizer fields, widget settings, theme options, and front-end forms should never trust raw request data.
• Review functions.php regularly. This file often becomes a catch-all for snippets copied from tutorials. Remove code you no longer use and move larger logic into a plugin when possible.
• Check upload and media-related customizations. If your theme adds custom upload flows, verify file type restrictions and capability checks.
• Review theme.json and editor settings. Restrict options that should not be broadly editable, especially on content teams with multiple roles. For theme-specific editor controls, see the theme.json reference guide and the WordPress block theme customization guide.

3. Checklist for custom plugins and plugin modification

• Avoid editing third-party plugins directly. Prefer hooks, filters, extension points, or your own companion plugin. Direct edits are hard to track and easy to lose during updates.
• Require capability checks on admin actions. If your plugin adds settings pages, AJAX actions, REST routes, export tools, or bulk actions, verify user permissions before the action runs.
• Use nonces for state-changing requests. Nonces help protect admin forms and action URLs from cross-site request forgery.
• Validate and sanitize all incoming data. This includes $_POST, $_GET, REST request payloads, webhook inputs, and data from third-party APIs.
• Escape all output. Especially in admin notices, settings pages, metaboxes, and front-end rendering functions.
• Review database queries. Use safe query methods and avoid building SQL from unsanitized user input.
• Check file operations. If the plugin writes files, imports CSV data, generates PDFs, or handles uploads, audit paths, file names, and permissions carefully.
• Secure cron jobs and scheduled tasks. Make sure recurring tasks cannot be abused by publicly accessible endpoints or weak callbacks.

If you are troubleshooting unusual behavior while auditing plugin code, this step-by-step guide to debug WordPress plugin conflicts is a good companion resource.

4. Checklist for snippet-heavy sites

• Inventory every snippet. Know where code lives: child theme, mu-plugin, custom plugin, snippet manager, or hosting panel.
• Delete duplicate or obsolete snippets. Many security issues start as maintenance issues from code no one remembers adding.
• Group related changes into plugins. A snippet is useful for small adjustments, but complex business logic belongs in a maintainable codebase.
• Review copied code from forums or tutorials. Confirm it matches current WordPress standards and does not expose admin-only behavior to the front end.
• Check hook priority and scope. A snippet may run in more places than intended, including admin screens, REST requests, or login pages.

5. Checklist for environment and hosting setup

• Separate local, staging, and production environments. Do not test custom code directly on a live site when avoidable.
• Use secure file permissions appropriate to your host. Permissions should be restrictive enough to reduce risk without breaking updates or uploads.
• Protect sensitive configuration. Database credentials, salts, API keys, and environment-specific secrets should not be casually shared in code repositories or screenshots.
• Restrict access to staging. Password-protect it or limit by IP if practical, especially when customer data exists there.
• Monitor logs. PHP warnings, fatal errors, login activity, and unusual request patterns can reveal weak points early. For a practical walkthrough, see the WordPress error log guide.
• Harden the database and hosting account too. WordPress security is broader than wp-admin. A compromised hosting panel or weak database access undermines everything above it.

6. Checklist for deployment and team workflow

• Use version control for custom code. Track who changed what and when.
• Review code before deployment. Even a lightweight review catches accidental debug statements, unsafe queries, and leftover test endpoints.
• Deploy from a known source of truth. Avoid ad hoc production edits that never make it back into the repository.
• Test on staging before pushing live. A simple release checklist reduces both breakage and security regressions. The staging site checklist for WordPress changes is useful here.
• Keep build tools predictable. If your theme or plugin uses bundlers, confirm production builds exclude development artifacts and source files that do not belong on the live site. See modern WordPress build tools compared for workflow context.
• Manage dependencies carefully. If you use Composer, lock dependency versions and review package sources. The guide on using Composer with WordPress themes and plugins can help structure this process.

What to double-check

These are the items that deserve a second pass because they are easy to overlook on custom WordPress sites.

Admin-only logic that leaks into front-end requests

Many custom functions begin life in the admin area and later affect public pages through hooks or shared helper functions. Recheck capability checks, nonce verification, and whether the code should run only in specific contexts.

Debug settings left enabled

Debugging is necessary during development, but production should not expose notices, stack traces, or filesystem paths to visitors. Double-check debug display settings, debug log locations, and whether error output could reveal plugin names, file paths, or internal logic.

REST API and AJAX endpoints

Custom endpoints deserve special scrutiny. Ask four questions: who can access this endpoint, what data can it read, what changes can it make, and how is input validated? Convenience endpoints built for internal use often become public attack surfaces if permissions are weak.

User roles and content editing controls

Security is not just about blocking attackers. It is also about preventing accidental damage by legitimate users. If editors can change layout settings, inject scripts, upload file types, or modify plugin options, review whether those permissions still match the team’s needs.

Abandoned code paths

Old shortcodes, legacy metaboxes, retired template parts, and deprecated plugin settings often remain in the codebase long after they stop being used. Removing dead code reduces maintenance burden and narrows the attack surface.

Performance-related choices that affect security

Poor performance can hide security problems. A plugin conflict, runaway query, or misconfigured cache can make monitoring harder and incident response slower. It is worth pairing this audit with a WordPress performance optimization checklist for custom themes and plugins, especially on heavily customized sites.

Common mistakes

Most custom WordPress security issues come from routine habits rather than advanced exploits. Watch for these patterns.

• Treating snippets as harmless because they are small. A five-line snippet can still expose sensitive behavior or bypass capability checks.
• Using production as a testing environment. Quick live fixes often create untracked changes and rollback headaches.
• Forgetting to secure staging and clones. A copied site with weak access controls is still your site.
• Keeping too much logic in functions.php. This makes code harder to review, test, and disable selectively during incidents.
• Relying on one security plugin as the whole strategy. Plugins can help, but they do not replace safe code and disciplined deployment.
• Ignoring error logs until something breaks publicly. Small warnings can reveal insecure assumptions before they become outages.
• Editing vendor or third-party plugin files directly. It creates an update trap and makes future audits harder.
• Leaving old administrator accounts active. Access control should be reviewed whenever team roles change.
• Not documenting customizations. If only one person knows why a filter exists or which plugin stores critical logic, the site becomes harder to secure over time.

A good rule is this: if a customization cannot be explained clearly, located quickly, and disabled safely, it needs cleanup.

When to revisit

This checklist is most useful when it becomes part of your recurring maintenance rhythm. Revisit it in these situations:

• Before a major launch or redesign.
• After installing or replacing plugins that interact with payments, user accounts, forms, or file uploads.
• When you change hosts, deployment tools, or build workflows.
• After adding custom REST endpoints, AJAX handlers, or admin settings pages.
• Before seasonal planning cycles or high-traffic campaigns.
• When team access changes.
• After unusual errors, unexplained slowdowns, or plugin conflicts.

For a practical routine, create a simple recurring audit with three passes:

1. Environment pass: users, backups, staging protection, debug settings, updates, permissions.
2. Code pass: child theme files, custom plugins, snippets, endpoints, forms, queries, output escaping.
3. Workflow pass: Git history, deployment steps, rollback readiness, dependency review, documentation.

Then record what changed. A short audit note is enough: what was reviewed, what was fixed, what needs follow-up, and who owns it. That small habit turns a one-off security check into a maintainable process.

For teams learning custom WordPress development, this is also where a structured modify WordPress course mindset helps. Security hardening is not separate from learning how to customize WordPress themes or plugins. It is part of doing custom WordPress development responsibly. The safer your workflow becomes, the easier it is to customize with confidence.

Use this checklist before you act, not after something goes wrong. On custom code sites, the safest fix is usually the one you planned for in advance.