# WP Security Ninja - full corpus > Generated from official markdown sources. Publisher: Larsik Corp. This file concatenates curated product, feature, docs, dictionary, and guide pages referenced from [llms.txt](https://wpsecurityninja.com/llms.txt). It is not a dump of the entire blog. --- ## About, history & future of Security Ninja ## Getting set up The [install wizard](/install-wizard/) gets the basics on, and import/export helps if you manage more than one site. Prefer reading first? There are [150+ docs](/docs/), including help from inside the plugin. On licenses with 25 or more sites, [white label](/whitelabel/) lets agencies brand the plugin for client work. The plugin is maintained and sold by [Larsik Corp](https://larsik.com/). See what we are building next on the [roadmap](/roadmap/). ## The history of Security Ninja Security Ninja celebrated its tenth birthday in 2021. In *internet years* that is a lot. Time flies, and at some point you realize it has been longer than it feels. Through the years what kept us going was the fact that people used it. Security Ninja kept sites safe, users informed, and us happy. We hope that will continue for another ten years, at least. Till then, here is a short history of Security Ninja's birth and growth. For what shipped after this origin story, see the live [changelog](/changelog/) and the year archives below. * **Early summer 2011** Security Ninja (it was called "Site Security Tester" in that first version) was made as an internal tool, used for testing the most common security issues on clients' sites. It had barely ten tests, but we installed it on every site to quickly check things we knew needed checking. * **September 27th, 2011** Security Ninja went live for sale on CodeCanyon! For a disturbingly low $8 you could have bought a lifetime license for unlimited sites. Not a very wise business decision, we know. But those were the prices back in the day. * **December 31st, 2011** After three months Security Ninja already racked 318 sales and was featured on CodeCanyon. Wayback machine has a [snapshot](https://web.archive.org/web/20111231031336/http://codecanyon.net:80/item/security-ninja/577696). The price was increased to a whopping $10. * **August 31st, 2012** Core Scanner add-on is released! First add-on in the series of four (on CC) for $6. Sales are still going strong; we're at 823. Which means Security Ninja sales almost 3 copies a day. From the initial ten tests, it's grown to 26. * **December 2nd, 2012** Security Ninja Lite added to the WordPress repository as a free plugin. This was the only terrible move we ever did with Security Ninja. It turns out nobody wants to use a "lite" version of a plugin. It never got any traction. * **December 23rd, 2012** Scheduled Scanner is released! For $6 you can automatically run Security Ninja and core scanner add-on tests. Security Ninja passed 1,100 sales and Core Scanner 150. * **August 9th, 2014** Third add-on released - Events Logger. Security Ninja is already a reputable brand and sales are still going strong. * **September 17th, 2014** To make purchasing more accessible, we created the Security Ninja Bundle. A package with all the add-ons and the main plugin. By this time Security Ninja has 2,500+ sales and Core Scanner 1,000+. * **March 5th, 2015** Fourth and last add-on on CodeCanyon released - Malware Scanner. Although the sales are still solid, the overall traffic and visibility on CodeCanyon is dropping significantly. * **August 30th, 2016** We pulled the trigger! Security Ninja is no longer available on CodeCanyon and the main module is now free and available on the [WordPress repository](https://wordpress.org/plugins/security-ninja/). All add-ons have been packed into one plugin - Security Ninja PRO which we're selling on our own. Technically we're utilizing the freemium but most sales come from the website, not from the free version. * **September 16th, 2016** Although we've started removing other plugins from CodeCanyon too, we've decided to put Security Ninja PRO back on it. But on our non-exclusive account since we're now selling SN on our own. No sales were expected and (almost) none were made. The move was made only for marketing benefits. * **April 9th, 2017** New module (ex add-on) - Auto Fixer. Nobody wants to mess with code if they can click one "fix" button, right? New tests are continuously added to the main module - we're now at 50+. After moving from CodeCanyon we lost a lot of traffic, but sales are still going strong. * **December 7th, 2017** After asking users what functionality is missing in Security Ninja PRO, we created the Database Optimizer module. A one-click solution to all database speed and maintenance problems. * **April 5th, 2018** Cloud Firewall is released! Ban 600 million bad IPs with one click and protect your login from brute-force attacks. ### Release notes by year The origin timeline above stops in 2018. Everything since then lives in the release notes. * [Current changelog](/changelog/) * [2025](/changelog/2025/) * [2024](/changelog/2024/) * [2023](/changelog/2023/) * [2022](/changelog/2022/) * [2021](/changelog/2021/) * [2020](/changelog/2020/) * [2019](/changelog/2019/) * [2018](/changelog/2018/) * [2017](/changelog/2017/) * [2016](/changelog/2016/) * [2011](/changelog/2011/) --- ## WordPress Cloud Firewall --- ## WordPress Malware Scanner --- ## WordPress Login Protection --- ## WordPress Security Tests --- ## WordPress Vulnerability Scanner --- ## 404 Guard for WordPress --- ## AI Security Advisor for WordPress --- ## White Label WordPress Security --- ## 404 scanning ## Why it matters for WordPress Bots do not only hit the homepage. They request thousands of paths that never existed: old plugin folders, `.env` backups, `wp-config.php.bak`, known exploit URLs. Each miss is a 404 that still costs PHP or server work. On cheap hosting, that noise shows up as slow sites and higher bills. ## How it shows up in practice - Access logs full of 404s for random PHP filenames - Spikes right after a popular CVE hits the news - Hosting panels warning about bot traffic or resource limits - Scanners looking for leftover zip backups in the web root ## What to do 1. Do not leave backup zips, `.sql` dumps, or `wp-config` copies in public directories. 2. Block or challenge the noisiest probe patterns at the firewall or host edge. 3. Keep plugins updated so “known path” exploits fail even when probed. 4. Watch whether 404 storms hide a quieter successful intrusion elsewhere. ## In WP Security Ninja [404 Guard](/404-guard/) helps cut scanners that hammer missing URLs. [Cloud Firewall](/cloud-firewall/) can block known-bad IPs and exploit-shaped requests before they chew through workers. Deeper context: [why 404s spike hosting bills](/404-hammering/). --- ## Account takeover ## Why it matters for WordPress If an Administrator account is taken over, the attacker can install plugins, create more admins, and plant backdoors. Takeover often starts with a reused password, a phishing page, or a session theft, not a clever zero-day. ## How it shows up in practice - Successful login from a country or device nobody recognizes - Password changed out from under the real owner - New Administrator users appearing after a quiet login - Email forwarding or notification settings altered to hide alerts ## What to do 1. Require unique passwords and 2FA on privileged roles before you need them. 2. Rate-limit login failures and review unusual successes. 3. If takeover is suspected, rotate passwords, revoke sessions/salts, and audit users and plugins. 4. Check the events log for the first odd success and everything after it. ## In WP Security Ninja [Login protection](/login-protection/) slows guessing and stuffing noise. [2FA](/two-factor-authentication-2fa/) blocks many takeovers even when the password is already known. The [Events Logger](/events-logger/) helps you see the surprise success and the admin creates that follow. --- ## Application passwords ## Why it matters for WordPress Mobile apps, CLI tools, and automations often need API access. Application passwords give them a revocable secret instead of storing the real admin password in a third-party service. They still carry the user’s capabilities. An app password on an Administrator is still administrator-level power if it leaks. ## How it shows up in practice - “Application Passwords” section on a user profile in wp-admin - REST or XML-RPC style basic auth using `username` + app password - Leftover app passwords for tools nobody uses anymore - Sites that disable the feature entirely when they have no integrations ## What to do 1. Create app passwords only for users who need the integration, preferably not shared god-accounts. 2. Revoke passwords when a tool is retired or a freelancer leaves. 3. Prefer the least privileged role that still works for the integration. 4. If you do not use any app integrations, disabling application passwords is a fair hardening choice. 5. 2FA on the human login still matters; app passwords are a separate secret to protect. --- ## Assume breach ## Why it matters for WordPress Perfect prevention fails eventually: a zero-day plugin hole, a phished editor, a vendor compromise. Teams that only “lock the door” freeze when something slips through. Assume breach means you can still answer what changed, restore cleanly, and hunt persistence. ## How it shows up in practice - A staging restore drill you actually ran last quarter - An events log that answers “who created that admin?” - Password and salt rotation as routine after incidents, not panic theater - A named person (or agency) who owns malware cleanup ## What to do 1. Practice a restore on staging before you need production heroics. 2. Keep event logging and file integrity checks on. 3. Write a one-page incident checklist while everyone is calm. 4. After any compromise, hunt persistence. Do not only delete the weird file. --- ## Backdoor ## Why it matters for WordPress Cleaning “the obvious malware file” while leaving a backdoor means reinfection days later. Backdoors hide in themes, mu-plugins, uploads with double extensions, or database options that eval code on every request. ## How it shows up in practice - Reinfection after a “successful” cleanup - Unknown PHP files with obfuscated names - Admin users or scheduled tasks that reappear - File changes when nobody is editing the site ## What to do 1. Assume multiple persistence mechanisms until proven otherwise. 2. Diff core and popular themes/plugins against clean copies. 3. Audit users, cron, mu-plugins, and `wp-config.php`. 4. Rotate credentials and invalidate sessions after cleanup. 5. Keep an events log so the next odd admin create is visible. ## In WP Security Ninja Scan with the [malware scanner](/malware-scanner/), then use the [Events Logger](/events-logger/) to catch new admins, plugin installs, and other odd changes if something tries to come back. Persistence deep dive: [WordPress backdoor hacks](/wordpress-backdoor-hacks-what-to-know/). --- ## Brute force ## Why it matters for WordPress WordPress exposes a public login URL on most sites. Bots can hit `wp-login.php` and `xmlrpc.php` all day with guessed passwords. One weak Administrator password is enough for a full takeover. ## How it shows up in practice - Sudden spikes of failed logins from many IPs - Lockouts or “too many attempts” messages for real users - A successful login from an unfamiliar country right after a wave of failures - XML-RPC multicall requests that try many passwords in one hit ## What to do 1. Use unique, long passwords (a password manager helps). 2. Turn on two-factor authentication for admins and editors. 3. Limit login attempts and block noisy IPs. 4. Disable or tightly restrict XML-RPC if you do not need it. 5. Watch the events log for new admin users and plugin installs after any suspected breach. ## In WP Security Ninja Pro [login protection](/login-protection/) rate-limits failed attempts and supports lockouts so guessing gets expensive. Pair it with [2FA](/two-factor-authentication-2fa/) for privileged roles, and review the [Events Logger](/events-logger/) when failure spikes are followed by a surprise success. --- ## Core file integrity ## Why it matters for WordPress Attackers sometimes patch a core file so their backdoor loads on every request. The site can look fine in wp-admin while `wp-includes` is no longer stock WordPress. Comparing core to official hashes catches that class of persistence even when malware signatures miss it. ## How it shows up in practice - Scanner reports that specific core files differ from expected checksums - Odd behavior after a “cleanup” that never reinstalled core - Manual edits someone made “just to fix a warning” inside core (also a problem) - Reinfection until the modified dropper file is replaced ## What to do 1. Scan core after incidents and on a regular schedule. 2. Investigate diffs; do not dismiss them because the homepage looks fine. 3. Reinstall core from trusted packages when tampering is confirmed (and avoid editing core going forward). 4. Pair with malware scanning and an events log for a full picture. ## In WP Security Ninja The [Core scanner](/core-scanner/) checks WordPress core files against known-good copies so unexpected edits stand out. Use it with the [malware scanner](/malware-scanner/) when you suspect quiet tampering rather than only spam redirects. --- ## Credential stuffing ## Why it matters for WordPress People reuse passwords. When another site leaks a list, attackers try those same pairs on WordPress. They are not guessing letter by letter. They are checking whether your users recycled a password from a breach dump. ## How it shows up in practice - Failed logins with many different usernames, each tried only a few times - Successful logins that look quiet (few failures) when the stuffed password was correct - Hits from residential proxies or rotating IPs that dodge simple bans - Agency shared logins that also appear in unrelated breach lists ## What to do 1. Never reuse the WordPress admin password elsewhere. 2. Require 2FA for privileged roles. 3. Force a password reset if you suspect a leaked account. 4. Rate-limit logins and review unusual success locations. 5. Treat obscure usernames as a small speed bump, not the main control. ## In WP Security Ninja Pro [login protection](/login-protection/) slows repeated failures, and [2FA](/two-factor-authentication-2fa/) means a stuffed password still needs a second factor for privileged roles. The [Events Logger](/events-logger/) records successes and failures so a quiet takeover is easier to spot after the fact. --- ## CSRF ## Why it matters for WordPress If an Administrator is logged in and visits a malicious page, that page can try to submit forms to `wp-admin` as the admin. WordPress core uses nonces to stop most of this. Custom plugins that skip nonce and capability checks stay risky. ## How it shows up in practice - A settings change or plugin install the admin does not remember - CVE write-ups that mention missing nonce checks on an AJAX or admin-post handler - Combined attacks: XSS plus CSRF to escalate impact from a lower foothold ## What to do 1. Keep WordPress and plugins updated (nonce bugs get patched). 2. For custom admin actions, verify nonces and real capabilities. 3. Log out of admin when browsing untrusted sites, or use a separate browser profile. 4. Prefer POST for state-changing actions; obscure URLs are not protection. --- ## CVE ## Why it matters for WordPress When a plugin hole goes public, it usually gets a CVE ID (and sometimes several related IDs). Scanners, hosts, and news posts use that ID so everyone means the same bug. Your job is not to memorize CVSS charts. It is to see whether your installed version is affected and whether a fixed release exists. ## How it shows up in practice - Advisory titles like “CVE-2026-##### in Plugin Name ≤ x.y.z” - Vulnerability scanners listing the ID next to severity and fixed version - Exploit posts that appear within hours of disclosure - Changelog lines that quietly say “security fix” without the CVE in the UI ## What to do 1. Match the affected versions to what you actually run. 2. Update to the fixed release when it exists; remove abandonware if it will never ship a fix. 3. If you must delay, mitigate (disable the plugin, restrict access, tighten the WAF) and set a deadline. 4. After patching, confirm the version and watch logs for probe traffic. --- ## DDoS ## Why it matters for WordPress Even a cheap flood can knock shared hosting offline. Application-layer floods aim at login, search, XML-RPC, or heavy plugin endpoints so a little traffic does a lot of damage. A security plugin alone cannot absorb a large network flood; that belongs at the CDN or host edge. ## How it shows up in practice - Timeouts while CPU or network is pegged - Huge request rates to one URL or to missing paths (404 storms) - Host or CDN abuse notices - A flood that hides a quieter intrusion attempt underneath ## What to do 1. Put the site behind a CDN or host WAF that absorbs volumetric noise. 2. Rate-limit login, XML-RPC, and other expensive endpoints. 3. Cache aggressively for anonymous traffic. 4. Work with the host when the flood is bigger than the app can handle. 5. After it calms down, check whether someone also tried to break in. ## In WP Security Ninja Large volumetric floods belong at the CDN or host edge. On the application side, [Cloud Firewall](/cloud-firewall/) can cut known-bad IPs, countries you do not serve, and exploit-shaped requests. [404 Guard](/404-guard/) helps with noisy probe traffic that hammers missing URLs. Neither replaces an edge DDoS service for a big network flood. --- ## Defense in depth ## Why it matters for WordPress There is no single “secure plugin” checkbox. Updates, backups, 2FA, a WAF, monitoring, and least privilege each catch different failures. Layers turn brittle security into something that survives a bad week. ## How it shows up in practice - A stuffed password that still fails because 2FA is on - An exploit probe blocked by a WAF while you patch the plugin - Odd admin activity in the events log before visitors see spam redirects - A tested backup that lets you rebuild when cleanup takes too long ## What to do 1. Pick a small stack you will actually maintain. 2. Prefer boring controls that work together over one exotic gadget. 3. Test restores; an untested backup is not a layer. 4. Review the stack yearly as the site and team change. --- ## Event logging ## Why it matters for WordPress When something goes wrong, memory is a bad forensic tool. A timeline of logins, plugin installs, option changes, and new users answers “who did that?” without guessing from a backup dump. ## How it shows up in practice - An unknown Administrator appears and nobody remembers creating it - A plugin activates overnight on a site nobody was editing - Failed login storms, then one success from a new country - Post-cleanup reviews where you need to prove what changed and when ## What to do 1. Enable an events log before you need it, not after the breach call. 2. Keep log data away from low-privilege roles that should not rewrite history. 3. Glance at the log after deploys, staff changes, and security alerts. 4. Retain enough history to cover “we noticed this a week late.” ## In WP Security Ninja The [Events Logger](/events-logger/) records logins, blocks, and site activity so you can rebuild a timeline after a scare. It pairs well with login protection and malware cleanup: the log shows the odd admin create or plugin install that the scanner alone will not explain. --- ## False negative ## Why it matters for WordPress A green “no malware found” badge feels great. It is not proof the site is clean. New backdoors, clever obfuscation, and database-only injections get missed. Pair scanners with integrity checks, logs, and human review when symptoms disagree with the report. ## How it shows up in practice - Visitors still see spam redirects while the scanner stays green - A host blacklist notice after your plugin said everything was fine - Reinfection from a persistence mechanism no signature knew yet - A known vulnerable plugin version that a misconfigured scan never listed ## What to do 1. Treat scanner output as evidence, not gospel. 2. If users report odd behavior, investigate anyway: logs, core diffs, users, cron. 3. Combine malware scanning with file integrity and vulnerability checks. 4. After cleanup, keep watching; false negatives love to show up on day two. --- ## False positive ## Why it matters for WordPress Scanners and WAFs err on the side of caution. Treating every flag as malware wastes hours. Ignoring every flag because “tools cry wolf” is how real infections linger. The skill is verification, not blind trust or blind dismissal. ## How it shows up in practice - A malware scanner flags obfuscated but legitimate library code inside a plugin - A core integrity alert right after a normal WordPress update - Host antivirus quarantines a needed plugin file and breaks checkout - A WAF blocks a payment webhook or a real customer’s unusual User-Agent ## What to do 1. Verify before mass-deleting: path, modification time, whether the code belongs to a known plugin version. 2. Compare with a clean copy of the same plugin or theme release. 3. Allowlist narrowly when you are sure; do not blank-allow whole directories. 4. For WAF noise, tune the rule or path instead of turning the firewall off. --- ## File integrity monitoring ## Why it matters for WordPress Attackers often tweak a core file, drop PHP under `uploads/`, or quietly edit `wp-config.php`. Integrity checks catch those edits even when a signature scanner has never seen that exact payload. ## How it shows up in practice - Alerts that a core file no longer matches wordpress.org hashes - New executable files outside expected plugin or theme paths - A diff right after a plugin update (sometimes benign; still worth a glance) - Reinfection clues: a “cleaned” file changes again overnight ## What to do 1. Compare core regularly, and again after any incident. 2. Investigate unexpected diffs before you dismiss them as noise. 3. Reinstall core (and suspect themes) from trusted packages when tampering is confirmed. 4. Pair integrity checks with malware scanning; they catch different failure modes. ## In WP Security Ninja The [Core scanner](/core-scanner/) checks WordPress core files against known-good copies so tampering stands out. Use it beside the [malware scanner](/malware-scanner/) when you suspect a quiet edit rather than an obvious spam redirect. --- ## File upload vulnerability ## Why it matters for WordPress WordPress sites upload media all day. When a form or plugin fails to validate type, size, or path, attackers upload `.php` (or double extensions) and browse to it. That is one of the most common ways webshells land. ## How it shows up in practice - PHP files under `wp-content/uploads` - CVE text about missing filetype checks on an AJAX upload handler - Contact forms or builders that accept “any file” into a web-reachable folder - Executed uploads even when the UI said “images only” ## What to do 1. Keep form and builder plugins updated; upload bugs are frequent. 2. Block PHP execution in uploads at the server when the host allows it. 3. Restrict who can upload; not every role needs `upload_files`. 4. After a bad upload, remove the file, close the hole, scan for siblings, rotate credentials. --- ## Incident response ## Why it matters for WordPress When a site is hacked, random clicking makes things worse. A simple response order protects visitors, preserves evidence, removes persistence, and closes the door. You do not need a Fortune 500 playbook. You need a one-page checklist you will actually follow. ## How it shows up in practice - Safe Browsing warnings, spam redirects, or a host suspension - Unknown admins, odd plugins, or PHP in uploads - The urge to “just restore a backup” without finding how they got in - Cleanup that works for a day, then the malware returns ## What to do 1. Contain harm (maintenance mode, host help) and take a forensic backup. 2. Regain clean admin access; reset passwords and sessions. 3. Remove malware and backdoors; compare core to clean copies. 4. Close the entry path (vulnerable plugin, weak admin, nulled zip). 5. Harden, monitor, and write down what you will do differently next time. Full walkthrough: [WordPress site hacked? Steps to recover](/what-should-you-do-if-your-wordpress-site-is-hacked/). --- ## Least privilege ## Why it matters for WordPress Every Administrator account is full keys to the kingdom. Freelancers, interns, and old agency logins with admin rights turn a small phishing win into a full takeover. Least privilege shrinks that blast radius before anything goes wrong. ## How it shows up in practice - Five Administrators when one break-glass account would do - Authors who somehow can install plugins - Shared “team” admin accounts nobody wants to rotate - Application passwords created with more power than the integration needs ## What to do 1. Map people to default roles (Editor, Author, Shop Manager) before creating more Admins. 2. Use a separate admin account for break-glass work; day-to-day on a lower role when possible. 3. Remove users who left the project. 4. Audit capabilities added by membership or ecommerce plugins. Related guide: [WordPress user roles](/wordpress-user-roles/). --- ## Login protection ## Why it matters for WordPress `wp-login.php` is the front door on almost every site. Bots do not care how small your blog is. Real protection is rate limits, lockouts, 2FA, and watching successes after failure spikes. Renaming the login URL alone is security theater. ## How it shows up in practice - Failed-login charts that climb, then flatten once limits kick in - Lockout notices for noisy IPs while staff still get in with 2FA - Quiet successful logins from stuffed passwords when 2FA was never required - XML-RPC or REST auth attempts that bypass a “pretty” custom login slug ## What to do 1. Unique passwords plus 2FA for Administrator and Editor. 2. Rate-limit failures and review the log after unusual spikes. 3. Restrict XML-RPC if nothing you run needs it. 4. Treat a surprise admin login as an incident until proven otherwise. ## In WP Security Ninja [Login protection](/login-protection/) handles attempt limits and related lockouts. [2FA](/two-factor-authentication-2fa/) covers privileged roles so a guessed or stuffed password is not enough on its own. The full walkthrough lives in the [WordPress login security guide](/wordpress-login-security-complete-guide/). --- ## Malware ## Why it matters for WordPress Infected sites lose trust, trip Safe Browsing warnings, and can hurt visitors. Deleting the one ugly PHP file often fails because a backdoor, cron job, or database option puts it back. That “it returned overnight” pattern is common. ## How it shows up in practice - Google Safe Browsing or host abuse notices - Redirects, spam SEO pages, or crypto miners chewing CPU - Mystery PHP under `uploads/`, or core and theme files that no longer match clean copies - New Administrator users or scheduled tasks nobody created - Symptoms that vanish for logged-in admins but hit logged-out visitors (cloaking) ## What to do 1. Take a forensic backup, then limit public harm (maintenance mode or host help). 2. Scan files and compare core against known-good hashes. 3. Remove malware and the entry path (weak passwords, vulnerable plugins, backdoors). 4. Rotate passwords, salts, and API keys after cleanup. 5. Re-scan and watch logs; if it returns, hunt persistence ([malware that kept coming back](/malware-kept-coming-back/)). ## In WP Security Ninja The [malware scanner](/malware-scanner/) helps find suspicious code and cleanup targets. Pair it with the [core scanner](/core-scanner/) and [Events Logger](/events-logger/) so you catch reinjection and odd admin activity, not only the first bad file. Step-by-step cleanup: [WordPress malware removal](/wordpress-malware-removal/). --- ## Nulled plugin ## Why it matters for WordPress “Free Pro download” sites do not remove the license check out of kindness. They often add webshells, spam injectors, or phone-home code. You trade a license fee for a persistent compromise that can outlive the plugin you thought you wanted. ## How it shows up in practice - Plugins installed from random zip sites or “GPL clubs” - Mystery admin users, odd cron jobs, or PHP in uploads after install - Update mechanisms that pull more malware later - Support nightmares: the real vendor will not help a pirated copy ## What to do 1. Buy or use legitimate free plugins from wordpress.org and known vendors. 2. Remove nulled copies immediately; treat the site as potentially compromised. 3. Scan for malware and backdoors, rotate credentials, regenerate salts. 4. Rebuild from clean sources when you cannot trust the file tree. Guide: [How to tell if a WordPress plugin is secure](/how-to-tell-if-a-wordpress-plugin-is-secure/). --- ## Phishing ## Why it matters for WordPress Attackers email “your site is hacked, log in here” or “WordPress needs urgent verification.” The fake page captures the password. 2FA helps a lot, but rush and fear still win when people click before they think. ## How it shows up in practice - Emails that rush you to click a login link - Domains that look almost like your host, registrar, or plugin vendor - Unexpected password-reset emails you did not request - A compromised site used to host phishing kits aimed at someone else’s brand ## What to do 1. Open admin bookmarks you typed yourself, not links from email. 2. Use 2FA and a password manager that will not autofill on lookalike domains. 3. Confirm urgent “security” messages through a second channel. 4. If you typed a password on a fake page, rotate it everywhere it was reused and review users and plugins. Full guide: [Phishing guide](/your-guide-to-phishing/). --- ## Plugin supply chain ## Why it matters for WordPress You inherit the security of every plugin author you install. Abandoned plugins, stolen publisher accounts, and pirated “nulled” packages keep showing up in incident reports. The update you clicked can be the delivery path. ## How it shows up in practice - Advisories about a popular plugin’s distribution or maintainer account - Nulled or “GPL club” zips that ship webshells beside the feature you wanted - Plugins that phone home or pull remote code at runtime without a clear reason - A critical CVE in a dependency you forgot was still active ## What to do 1. Install fewer plugins; remove what you do not use. 2. Prefer wordpress.org and known vendors. Never random null dumps. 3. Watch for odd new files right after an update. 4. Have a patch plan when a critical CVE hits something you depend on. 5. Prefer maintained plugins with a clear owner over abandoned one-offs. Guide: [How to tell if a WordPress plugin is secure](/how-to-tell-if-a-wordpress-plugin-is-secure/). --- ## Privilege escalation ## Why it matters for WordPress A bug that lets a Subscriber update options or upload PHP is effectively a full site takeover. Many plugin CVEs are labeled “authenticated privilege escalation.” Spam registrations plus one of those bugs is a common combo. ## How it shows up in practice - New Administrator accounts created by a lower role - Advisory text: “Subscriber+ can … leading to RCE / admin access” - Capability checks that only test `is_user_logged_in()` instead of a real capability - Membership or form plugins that quietly grant `upload_files` or worse ## What to do 1. Update plugins when privilege-escalation CVEs appear. Do not wait for “it looks unused.” 2. Keep open registration honest; spam accounts add attack surface. 3. Monitor user role changes in an events log. 4. Apply least privilege so fewer accounts start near the danger line. --- ## Rate limiting ## Why it matters for WordPress Without limits, bots can try thousands of passwords per hour against `wp-login.php` and `xmlrpc.php`. That burns server resources and raises the odds that a weak password eventually works. Soft limits turn the spray into a slow, noisy process you can detect and block. Rate limiting is not the same as a permanent ban list. Good limits slow attackers while still letting real users recover from a typo. ## How it shows up in practice - Temporary lockouts after N failed logins from one IP - HTTP 429 responses from a CDN, host, or application firewall - Firewall rules that throttle a path (login, XML-RPC, search, checkout) - Staff hitting limits from a shared office IP if the threshold is too strict ## What to do 1. Rate-limit WordPress login and XML-RPC if you still expose them. 2. Prefer progressive delays or short temporary bans over permanent locks attackers can use to DoS real users. 3. Allowlist trusted office or monitoring IPs carefully when staff share one egress address. 4. Pair limits with [two-factor authentication](/dictionary/two-factor-authentication/) so a successful guess still needs a second factor. 5. Watch failed-login volume in your events log after you tighten thresholds. ## In WP Security Ninja Pro [login protection](/login-protection/) includes configurable failed-login limits: after too many bad attempts, further tries are blocked for that visitor instead of hammering PHP forever. Combine that with 2FA on admin roles when you want stolen or stuffed passwords to fail even if they are “correct.” --- ## Remote code execution ## Why it matters for WordPress RCE is near the top of the severity ladder. If a plugin or theme flaw lets someone execute PHP or shell commands, they can drop a webshell, read `wp-config.php`, or pivot further. Public RCE CVEs get scanned quickly. Treat them as drop-everything updates. ## How it shows up in practice - Advisories labeled critical with “unauthenticated RCE” or “authenticated RCE” - New PHP files appearing after exploit traffic in the logs - Host notice that the account was used to attack other sites - Privilege-escalation bugs that chain into code execution ## What to do 1. Update or remove the affected component as soon as a fix exists. 2. If you cannot patch yet, disable the plugin and restrict access while you plan. 3. After any suspected RCE, assume compromise: scan, rotate secrets, hunt backdoors. 4. Keep file upload and capability checks honest in custom code so you do not invent your own RCE. --- ## REST API ## Why it matters for WordPress `/wp-json/` is how the block editor and countless plugins talk to WordPress. It is also a discovery surface: user enumeration, authenticated routes, and plugin endpoints that forget capability checks. Killing the entire REST API often breaks Gutenberg. The job is to understand what you expose, not to yank the fuse blindly. ## How it shows up in practice - Enumerated users via public author or user routes (when not restricted) - Brute force or stuffing against application-password protected routes - Plugin REST endpoints with weak permission callbacks in CVE write-ups - Headless or mobile apps that depend on specific namespaces staying open ## What to do 1. Keep WordPress and plugins updated; many REST bugs are permission mistakes. 2. Prefer application passwords or proper OAuth-style flows over sharing the main admin password with apps. 3. Rate-limit abusive auth attempts the same way you would for `wp-login.php`. 4. Only disable specific routes you do not need, and test the editor after changes. 5. Treat XML-RPC and REST as related surfaces: close what you do not use, harden what you do. --- ## Scheduled scanning ## Why it matters for WordPress Manual scans only happen when someone remembers. Attackers and new CVEs do not wait for your Monday checklist. A schedule turns scanning into a habit: malware, vulnerabilities, or integrity drift show up in email or the dashboard while you are busy elsewhere. ## How it shows up in practice - Nightly or weekly scan jobs with a short report - Email when a new finding appears after a previously clean run - Agencies running the same cadence across many client sites - Scans timed off peak so shared hosting does not hitch during business hours ## What to do 1. Pick a cadence you will actually review (daily for high-risk shops, weekly for quieter sites is common). 2. Make sure alerts reach a mailbox someone reads. 3. Investigate new findings promptly; a schedule is useless if nobody opens the report. 4. Re-scan after cleanups and major plugin changes. ## In WP Security Ninja The [scheduled scanner](/scheduled-scanner/) runs checks on a timetable and can email reports so you are not relying on memory. Pair it with the [malware scanner](/malware-scanner/) and [vulnerability scanner](/vulnerabilities/) so the schedule covers the checks you care about. --- ## Security audit ## Why it matters for WordPress Gut feel is not a plan. An audit turns “we should be more secure” into ordered work: outdated plugins, leftover admins, missing backups, open XML-RPC, weak login controls. Agencies use the same pass before launch or after a scare. ## How it shows up in practice - Scored security tests with pass/fail items you can re-run - A spreadsheet of plugin versions next to known CVEs - External review notes before go-live or after a compromise - Monthly checks on client sites where nobody watches the dashboard daily ## What to do 1. Inventory software, users with elevated roles, and backup restore proof. 2. Run automated tests, then verify anything that looks wrong (false positives happen). 3. Fix high-impact issues first: admin access, known CVEs, missing restores. 4. Re-run after changes so the report matches the live site. ## In WP Security Ninja [Security tests](/security-tests/) give a structured hardening checklist you can re-run after fixes. Combine them with the [vulnerability scanner](/vulnerabilities/) so configuration issues and known CVEs show up in one review cycle. Full walkthrough: [WordPress security audit guide](/wordpress-security-audit-guide/). --- ## Security hardening ## Why it matters for WordPress Default WordPress is usable, not maximally strict. Hardening shrinks what attackers can touch: fewer plugins, tighter roles, locked file editing, current software, tested backups. It is different from security theater (rename the login URL and call it done). ## How it shows up in practice - `DISALLOW_FILE_EDIT` so themes are not edited from the dashboard - XML-RPC or unused REST surfaces restricted - HTTPS done properly, security headers where they help - A short plugin list and a restore you have actually tried once ## What to do 1. Start with updates, strong admin hygiene, and a backup you have restored. 2. Remove unused themes and plugins. 3. Harden roles and login before exotic obscurity tricks. 4. Document what you changed so the next developer does not undo it blindly. Guide: [WordPress security hardening](/wordpress-security-hardening-guide/). --- ## Security headers ## Why it matters for WordPress Headers will not patch a vulnerable plugin. They still reduce common browser-side risks: forcing HTTPS (HSTS), blocking easy clickjacking, tightening what scripts can run when you use CSP carefully. Many hosts and CDNs can send them without a plugin pile-on. ## How it shows up in practice - `Strict-Transport-Security` on an HTTPS site - `X-Frame-Options` or `frame-ancestors` limiting who can iframe you - `Content-Security-Policy` that breaks a page builder if set too tight on day one - Security test checklists that flag missing headers on production ## What to do 1. Finish HTTPS properly before turning on HSTS with a long max-age. 2. Start with simple framing protections, then consider CSP once you can test the front end. 3. Prefer host or CDN configuration when you can; fewer moving parts in WordPress. 4. Re-test checkout, embeds, and admin after any header change. --- ## Security theater ## Why it matters for WordPress Renaming `wp-login.php`, hiding the generator meta tag, or stacking five overlapping “security” plugins can feel productive while admin passwords stay weak and backups stay untested. Attackers automate the boring holes. They do not need your version string. ## How it shows up in practice - Obscurity tricks treated as the whole strategy - Alert fatigue from noisy tools nobody reviews - Checklists that skip restores, 2FA, and updates - A “hardened” site that still runs an abandoned plugin with a public CVE ## What to do 1. Rank controls by how often they stop real incidents. 2. Drop overlapping plugins that fight each other. 3. Keep obscurity as optional garnish, not the meal. 4. Measure success by fewer incidents and faster recovery, not badge count. --- ## Session hijacking ## Why it matters for WordPress Admin cookies are powerful. XSS, malware on a workstation, or cleartext HTTP can expose them. After a hijack, the attacker does not need the password until the session ends. That is why HTTPS, XSS patching, and salt rotation after incidents matter together. ## How it shows up in practice - Actions in the events log while the real admin was asleep or offline - Simultaneous sessions from distant locations - Post-XSS cleanup that forgot to invalidate sessions - Shared computers that still have a “remember me” admin cookie ## What to do 1. Serve the whole site over HTTPS. 2. Patch XSS issues quickly. 3. Log out shared computers; avoid “remember me” on untrusted devices. 4. After a compromise, rotate passwords and invalidate sessions (regenerate salts if needed). 5. Keep privileged accounts on 2FA so password reuse alone is not enough later. --- ## SQL injection ## Why it matters for WordPress Plugins and custom code that build SQL with raw request data can expose posts, users, or the whole database. On WordPress, that usually means a vulnerable extension, not core itself. Public CVEs get automated fast. ## How it shows up in practice - Odd query strings that dump content or database error text - Unexpected admin users or option changes with no human action in the log - Scanner or advisory notes flagging a plugin CVE that mentions SQLi ## What to do 1. Keep WordPress, themes, and plugins updated. 2. Remove unused plugins and themes. 3. Prefer well-maintained extensions; check vulnerability databases when a CVE drops. 4. For custom code, use `$wpdb->prepare` and never concatenate untrusted input into SQL. 5. After a suspected SQLi incident, rotate secrets, audit users, and scan files. Full walkthrough: [SQL injection on WordPress](/what-is-an-sql-injection-attack/). --- ## SSL/TLS ## Why it matters for WordPress Login forms, cookies, and customer data should never ride cleartext HTTP. Browsers mark non-HTTPS sites as insecure, which hurts trust and SEO. HTTPS protects the pipe. It does not fix an outdated plugin with a public CVE. ## How it shows up in practice - Padlock (or a scary certificate warning) in the browser - Certificate expiry that takes the shop offline with a browser interstitial - Mixed content: an HTTPS page still loading HTTP scripts or images - Admin cookies safer in transit, but still stealable via XSS if you leave holes open ## What to do 1. Force HTTPS at the host or in WordPress site URLs. 2. Monitor certificate expiry (many hosts auto-renew Let’s Encrypt). 3. Fix mixed content so scripts and forms stay on HTTPS. 4. Keep patching; transport encryption is one layer, not the whole stack. Guide: [HTTPS and SSL/TLS certificates](/basic-guide-to-understanding-ssl-certificates/). --- ## Two-factor authentication (2FA) ## Why it matters for WordPress Passwords leak from other sites, phishing, and shared agency logins. 2FA means the password alone should not open `wp-admin`. For site owners and agencies, it is one of the highest-value controls you can turn on in an afternoon. ## How it shows up in practice - An authenticator prompt after the password on Administrator (and ideally Editor) - Recovery codes stored offline for a lost phone - Stuffing attempts that succeed on the password step, then fail without the code - Support tickets from staff who need a recovery path after a device change ## What to do 1. Require 2FA for all privileged roles, not only your personal admin. 2. Store recovery codes somewhere safe (ideally not in the same note as the password). 3. Prefer app-based TOTP over SMS when you have the choice. 4. Keep login rate limits on so stuffing still costs the attacker time. ## In WP Security Ninja [Two-factor authentication](/two-factor-authentication-2fa/) adds app or email codes for key roles. Use it with [login protection](/login-protection/) so bots cannot spray forever while someone without 2FA still sits on Administrator. Broader login hardening: [WordPress login security guide](/wordpress-login-security-complete-guide/). --- ## Vulnerability ## Why it matters for WordPress Most breaches start with a known vulnerable plugin or theme, not a brand-new zero-day against core. Automated scanners look for unpatched versions within hours of a public advisory. Severity and fixed-version notes tell you whether to update today or tonight. ## How it shows up in practice - CVE identifiers and changelog lines that say “security fix” - Scanner results listing component, installed version, and severity - Public write-ups with exploit details that bots soon automate - A plugin you forgot about, still active, years behind on updates ## What to do 1. Know what is installed and which versions are live. 2. Update when a fix ships; remove abandonware you cannot patch. 3. If you cannot update yet, mitigate: WAF rules, disable the plugin, restrict access. 4. After patching, confirm the version and watch logs briefly for probe traffic. ## In WP Security Ninja The [vulnerability scanner](/vulnerabilities/) flags known issues in installed plugins, themes, and core so you are not waiting on a news roundup. Pair it with [security tests](/security-tests/) and a patch habit. Reference: [WordPress vulnerabilities](/wordpress-vulnerabilities-database/). --- ## WordPress WAF ## Why it matters for WordPress A WordPress-oriented WAF sits at the edge or in the app and stops noisy exploit probes, bad bots, and known attack shapes. It is not a substitute for updates. It buys time and cuts drive-by noise while you patch. Think in layers: a CDN or host edge absorbs big floods; an application WAF understands WordPress URLs and login abuse; neither replaces clean code and current plugins. ## How it shows up in practice - Blocked requests in a firewall log (scanners, injection-shaped payloads) - Country or IP rules for traffic you never serve - Rules aimed at login abuse, 404 hammering, or popular CVE paths - Occasional false positives that break a webhook or a real customer checkout ## What to do 1. Use a WAF suited to WordPress traffic, not only a blunt “block a country” toggle. 2. Review false positives so real users, cron, and payment callbacks still work. 3. Keep patching; a WAF does not retire a known vulnerable plugin forever. 4. Watch logs after big CVE news when exploit traffic spikes. ## In WP Security Ninja [Cloud Firewall](/cloud-firewall/) filters malicious and unwanted requests before they reach WordPress, including IP and country controls when you need them. Use it with patching and the [malware scanner](/malware-scanner/), not instead of them. Deeper context: [WordPress firewalls](/what-you-should-know-about-wordpress-firewalls/). --- ## Webshell ## Why it matters for WordPress One PHP file in uploads or a theme can give filesystem and database access. Attackers use webshells to plant more malware, steal dumps, or pivot to other sites on shared hosting. Cleanup that misses the shell (or the upload hole) invites reinfection. ## How it shows up in practice - PHP files under `wp-content/uploads` - Tiny names like `x.php`, `1.php`, or random strings next to images - POST requests to odd paths in access logs - File integrity alerts for new executable paths outside plugins ## What to do 1. Block PHP execution in uploads at the server level when you can. 2. Scan for unexpected PHP outside normal plugin and theme code. 3. Trace how it got there (vulnerable form, plugin, FTP credentials). 4. Remove the shell, close the entry point, rotate credentials. 5. Compare core so modified droppers are not missed. ## In WP Security Ninja Use the [malware scanner](/malware-scanner/) to find suspicious PHP and the [core scanner](/core-scanner/) to catch unexpected core edits. After cleanup, keep scanning until findings stay clean. Persistence patterns: [WordPress backdoor hacks](/wordpress-backdoor-hacks-what-to-know/). --- ## WordPress nonce ## Why it matters for WordPress Core and well-built plugins attach nonces to admin forms and AJAX calls so a random third-party page cannot easily forge those actions while you are logged in. A missing or unchecked nonce shows up in CVE write-ups constantly. A nonce is not encryption, and it is not a substitute for capability checks. ## How it shows up in practice - Hidden `_wpnonce` fields on settings forms - URLs with `?_wpnonce=` on one-click actions - Advisories that say “missing nonce verification” on a privileged endpoint - Expired nonce errors after leaving an admin tab open too long ## What to do 1. Keep WordPress and plugins updated when nonce-related bugs ship. 2. In custom code, verify nonces and `current_user_can( ... )` together. 3. Do not treat “the URL is obscure” as protection. 4. If you build admin UI, fail closed when the nonce is missing or wrong. --- ## WordPress salts ## Why it matters for WordPress `AUTH_KEY`, `SECURE_AUTH_KEY`, and the other salts in `wp-config.php` make session cookies and nonces harder to forge. If those secrets leak (or you inherited a site with keys copied from a tutorial), attackers have an easier time with stolen cookies. Regenerating salts invalidates existing sessions. That is often what you want after a breach. ## How it shows up in practice - Eight long random constants near the top of `wp-config.php` - Everyone logged out after you rotate salts (expected) - Compromised sites that still work for the attacker until salts and passwords both change - Starter configs that reused the same example keys across many sites ## What to do 1. Use unique, randomly generated keys from a trusted generator (WordPress.org provides one). 2. After a compromise, regenerate salts and rotate passwords together. 3. Never commit real salts to a public repository. 4. Keep `wp-config.php` out of web-reachable backup dumps. --- ## WordPress user roles ## Why it matters for WordPress Roles are how WordPress encodes trust. Misassigned roles are a common root cause of “someone changed the site and we do not know who.” Administrator can install plugins and edit code paths; Editor usually should not. ## How it shows up in practice - Subscriber, Contributor, Author, Editor, Administrator (plus Super Admin on Multisite) - Plugins adding custom roles (Shop Manager, Customer, SEO Editor) - Capability checks in code: `current_user_can( 'manage_options' )` - Authors can upload media; Contributors cannot publish or upload by default ## What to do 1. Learn the default role ladder before inventing custom ones. 2. Prefer Editor for content teams; reserve Administrator for people who install plugins. 3. Review roles after major plugin installs that add capabilities. 4. Pair privileged roles with 2FA. 5. Log role and capability changes so surprise admins are visible. Full guide: [WordPress user roles](/wordpress-user-roles/). --- ## wp-config.php ## Why it matters for WordPress If `wp-config.php` leaks, attackers get database access and authentication salts. Malware also loves to inject PHP here because the file loads on every request. One quiet edit can persist long after you delete an obvious webshell. ## How it shows up in practice - Database name, user, password, and table prefix in plain PHP constants - `AUTH_KEY` and related salts that sign cookies and nonces - Flags like `DISALLOW_FILE_EDIT`, `WP_DEBUG`, and custom memory limits - Integrity alerts when the file changes and nobody deployed ## What to do 1. Keep the file outside the web root when the host supports it, or at least non-readable to the world. 2. Never commit real secrets to a public git repo. 3. Turn off public debugging on production (`WP_DEBUG` display off). 4. After a breach, rotate DB passwords and regenerate salts. 5. Watch integrity scans for unexpected edits to this file. --- ## XML-RPC ## Why it matters for WordPress `xmlrpc.php` can allow many password attempts in one HTTP request (multicall) and has been used in pingback-based floods. Plenty of modern sites do not need it. Leaving it open without limits is free attack surface. ## How it shows up in practice - High traffic to `/xmlrpc.php` in access logs - Brute-force attempts that barely touch the normal login form - Jetpack, older mobile apps, or automation still calling XML-RPC (check before you disable) - CPU spikes on cheap hosting from multicall storms ## What to do 1. Disable or block XML-RPC if nothing you use needs it. 2. If you need it, rate-limit and monitor closely. 3. Prefer the REST API with solid authentication for new integrations. 4. Confirm Jetpack, apps, and automation still work after any change. ## In WP Security Ninja If you still need XML-RPC, keep [login protection](/login-protection/) limits on and consider cutting noisy abuse with the [Cloud Firewall](/cloud-firewall/). If nothing needs it, disable or block it at the host or firewall layer. Broader login hardening: [WordPress login security guide](/wordpress-login-security-complete-guide/). --- ## Cross-site scripting (XSS) ## Why it matters for WordPress Stored XSS in a comment, page builder field, or admin notice can run in another user’s browser. For admins, that can mean stolen cookies, forced actions, or malware shown to visitors. Reflected XSS often rides on crafted URLs in plugins. ## How it shows up in practice - Unexpected popups, redirects, or injected ads on the front end - Admin screens that behave oddly after viewing crafted content - Scanner or CVE notes mentioning reflected or stored XSS in a plugin ## What to do 1. Update vulnerable plugins and themes quickly. 2. Limit who can publish unfiltered HTML. 3. Sanitize and escape output in custom themes and plugins. 4. Use a content security policy where practical (hosting or edge). 5. Treat odd JavaScript on your pages as an incident: scan, review recent content, check users. Full guide: [WordPress XSS attacks](/understanding-and-preventing-wordpress-xss-attacks/). --- ## Zero trust ## Why it matters for WordPress “We are on the office VPN so we are safe” does not match remote teams and cloud hosts. For WordPress, zero trust looks like strong identity checks, least privilege, and less surprise when a laptop or freelancer account goes missing. ## How it shows up in practice - 2FA on every Administrator and Editor - Separate staging credentials from production - No shared “the agency login” with a sticky-note password - Hosting panels and deploy keys locked down like production admin ## What to do 1. Verify users (password plus 2FA), not just IP allowlists. 2. Split duties: deploy keys are not content editor accounts. 3. Expire access when freelancers leave a project. 4. Prefer short-lived tokens for integrations over immortal application passwords when you can. --- ## WP Security Ninja ### Welcome to WP Security Ninja Documentation This documentation provides you with all the necessary information to maximize your use of our plugin, from setup to advanced security measures. If you have questions or need assistance, [our support team is ready to help](/help/). ## [AI Security Advisor](/docs/security-advisor/) 3 * [What happens when you generate a report](/docs/security-advisor/what-happens-when-you-generate-a-report/) * [How to enable AI Security Advisor](/docs/security-advisor/how-to-enable-ai-security-advisor/) * [How to get your first security report](/docs/security-advisor/security-report/) [View all 3 articles](/docs/security-advisor/) ## [Installation and usage](/docs/installation-and-usage/) 18 * [Install Security Ninja](/docs/installation-and-usage/install/) * [Install Pro version](/docs/installation-and-usage/install-pro-version/) * [Installation Wizard](/docs/installation-and-usage/installation-wizard/) * [How to access your website via FTP](/docs/installation-and-usage/how-to-access-your-website-via-ftp/) * [Does Security Ninja Work with WordPress.org?](/docs/installation-and-usage/wordpress-com/) * [How to include custom code on your website](/docs/installation-and-usage/custom-code-website/) * [Remove settings when deactivating](/docs/installation-and-usage/remove-settings-when-deactivating/) * [Dashboard Widget with quick site overview](/docs/installation-and-usage/dashboard-widget-with-quick-site-overview/) * [Last Login](/docs/installation-and-usage/last-login/) * [Activate Default Security Measures](/docs/installation-and-usage/activate-default-security-measures/) * [Data Processing Agreement](/docs/installation-and-usage/data-processing-agreement/) [View all 18 articles](/docs/installation-and-usage/) ## [Firewall](/docs/firewall/) * [How to use the firewall](/docs/firewall/how-to-use-the-firewall/) * [How to get back in to your website](/docs/firewall/how-to-get-back-in-to-your-website/) * [How to restore access without the unblock URL](/docs/firewall/how-to-restore-access-without-the-unblock-url/) * [Block IP Network](/docs/firewall/block-ip-network/) * [Change login URL](/docs/firewall/change-login-url/) * [How to ban subnet mask IP range](/docs/firewall/ban-subnet-mask/) * [Login Form Protection](/docs/firewall/login-form-protection/) * [Whitelisting Services in WP Security Ninja](/docs/firewall/whitelisting-services-in-wp-security-ninja/) * [Secret Access URL](/docs/firewall/secret-access-url/) * [Automatically Validated Crawlers](/docs/firewall/automatically-validated-crawlers/) [View all articles](/docs/firewall/) ## [MainWP](/docs/mainwp/) 9 * [How to Install and Set Up Security Ninja with MainWP](/docs/mainwp/install-security-ninja-mainwp/) * [How to Control White Label Settings Remotely](/docs/mainwp/how-to-control-white-label-settings-remotely/) * [Using Security Ninja tokens in MainWP Pro Reports](/docs/mainwp/using-security-ninja-tokens-in-mainwp-pro-reports/) * [Install the Free MainWP Extension for Security Ninja](/docs/mainwp/install-the-mainwp-extension-for-security-ninja/) * [Get started with Security Ninja and MainWP](/docs/mainwp/get-started-mainwp/) * [How to access Security Ninja in MainWP Dashboard](/docs/mainwp/how-to-access-security-ninja-in-mainwp-dashboard/) * [Bulk Actions in MainWP](/docs/mainwp/bulk-actions-in-mainwp/) * [How to Show/Hide the column](/docs/mainwp/how-to-show-hide-the-column/) * [The Global Event Log](/docs/mainwp/the-global-event-log/) [View all 9 articles](/docs/mainwp/) ## [Vulnerabilities](/docs/vulnerabilities/) * [What does "plugin closed" mean?](/docs/vulnerabilities/plugin-closed/) * [Email Alerts for Detected Vulnerabilities](/docs/vulnerabilities/email-alerts-for-detected-vulnerabilities/) * [How to use the vulnerability scanner](/docs/vulnerabilities/how-to-use-the-vulnerability-scanner/) * [How the vulnerability scanner works](/docs/vulnerabilities/scanner/) * [Dangers of Outdated Plugins](/docs/vulnerabilities/outdated-plugins/) * [What is the outdated.dat file?](/docs/vulnerabilities/what-is-the-outdated-dat-file/) * [Problems with the vulnerability scanner](/docs/vulnerabilities/problems-with-the-vulnerability-scanner/) [View all articles](/docs/vulnerabilities/) ## [Account](/docs/account/) 24 * [My account page](/docs/account/my-account-page/) * [Non-Sensitive Diagnostic Data](/docs/non-sensitive-diagnostic-data/) * [Keeps getting logged out](/docs/account/keeps-getting-logged-out/) * [Cancel subscription](/docs/account/cancel-subscription/) * [Forgotten password](/docs/account/forgotten-password/) * [Change account](/docs/account/change-account/) * [Does the plugin work with WordPress Multisite?](/docs/account/does-the-plugin-work-with-wordpress-multisite/) * [Problems logging in](/docs/account/problems-logging-in/) * [Military and Veteran Discounts](/docs/account/military-and-veteran-discounts/) * [Delete my account](/docs/account/delete-account/) * [Controlling License Usage by Whitelisting Sites](/docs/account/whitelist-sites/) [View all 24 articles](/docs/account/) ## [Security Tests](/docs/security-tests/) 29 * [Security Tests](/docs/security-tests/security-tests/) * [Security Issues were found](/docs/security-tests/security-issues-were-found/) * [Update functions.php](/docs/security-tests/update-functions-php/) * [Fix - temporary folder not writable](/docs/security-tests/fix-temporary-folder-not-writable/) * [Secure or remove readme.html](/docs/security-tests/secure-readme-html/) * [What is the sn-backups folder?](/docs/security-tests/what-is-the-sn-backups-folder/) * [Check if plugins are up to date](/docs/security-tests/check-if-plugins-are-up-to-date/) * [If full WordPress version info is revealed in meta data](/docs/security-tests/if-full-wordpress-version-info-is-revealed-in-meta-data/) * [User “admin” with administrator privileges exists](/docs/security-tests/user-admin-with-administrator-privileges-exists/) * [“Anyone can register” option is enabled](/docs/security-tests/anyone-can-register-option-is-enabled/) * [Unnecessary information on failed login attempts](/docs/security-tests/unnecessary-information-on-failed-login-attempts/) [View all 29 articles](/docs/security-tests/) ## [License](/docs/license/) 12 * [How to change your license key](/docs/license/how-to-change-your-license-key/) * [License activation problems](/docs/license/license-activation-problems/) * [How to upgrade from annual to lifetime license](/docs/license/upgrade-to-lifetime/) * [How to upgrade your license](/docs/license/how-upgrade-license/) * [Can I Resell or Transfer My License?](/docs/license/resell-license/) * [How to use license on another website](/docs/license/remove-website-from-license/) * [License Recovery for Security Ninja](/docs/license/license-recovery/) * [How to renew manually](/docs/license/how-to-renew-manually/) * [How To Renew Your License Early or Apply a Coupon](/docs/license/renew-license-early-coupon/) * [Early License Renewal & Proration](/docs/license/early-license-renewal-proration/) * [Automated License Activation for Multiple Sites - license\_key.txt](/docs/license/automated-license-activation-for-multiple-sites-license-txt/) [View all 12 articles](/docs/license/) ## [Troubleshooting and debugging](/docs/errors-and-debugging/) 18 * [How to locate JavaScript conflicts](/docs/errors-and-debugging/how-to-locate-js-conflicts/) * [How to create an admin account](/docs/errors-and-debugging/how-to-create-an-admin-account/) * [Virus detected in plugin?](/docs/errors-and-debugging/virus-detected-in-plugin/) * [Fix errors showing up frontend](/docs/errors-and-debugging/fix-errors-showing-up-frontend/) * [Debug - Get server and website information](/docs/errors-and-debugging/debug-get-server-and-website-information/) * [How to use WP\_DEBUG](/docs/errors-and-debugging/finding-errors-and-solutions/) * [Jetpack compatibility](/docs/errors-and-debugging/jetpack-compatibility/) * [Many admin-ajax.php requests](/docs/errors-and-debugging/many-admin-ajax-php-requests/) * [Parts of admin load via HTTP](/docs/errors-and-debugging/parts-of-admin-load-via-http/) * [Increase WordPress memory limit](/docs/errors-and-debugging/increase-wordpress-memory-limit/) * [Failed to connect to api.freemius.com](/docs/errors-and-debugging/failed-to-connect-to-api-freemius-com/) [View all 18 articles](/docs/errors-and-debugging/) ## [Filters and hooks](/docs/filters-hooks/) 12 * [securityninja\_whitelist filter](/docs/filters-hooks/securityninja_whitelist/) * [Filter - user\_agent\_items](/docs/filters-hooks/filter-user_agent_items/) * [Filter - securityninja\_visitorlog\_filter\_url](/docs/filters-hooks/filter-securityninja_visitorlog_filter_url/) * [Filter - blocked\_hosts\_items](/docs/filters-hooks/filter-blocked_hosts_items/) * [securityninja\_ignored\_file\_extensions](/docs/filters-hooks/securityninja_ignored_file_extensions/) * [Customizing Firewall Filter Rules](/docs/filters-hooks/customizing-firewall-filter-rules/) * [secnin\_show\_woocommerce\_login\_message](/docs/filters-hooks/secnin_show_woocommerce_login_message/) * [Filter. securityninja\_social\_crawler\_user\_agents](/docs/filters-hooks/filter-securityninja_social_crawler_user_agents/) * [securityninja\_temporary\_login\_params](/docs/filters-hooks/securityninja_temporary_login_params/) * [securityninja\_is\_temporary\_login\_link](/docs/filters-hooks/securityninja_is_temporary_login_link/) * [securityninja\_malware\_exclude\_paths](/docs/filters-hooks/securityninja_malware_exclude_paths/) [View all 12 articles](/docs/filters-hooks/) ## [Visitor Log](/docs/visitor-log/) 2 * [What is the visitor log](/docs/visitor-log/what-is-the-visitor-log/) * [Change how long visitor logs are kept](/docs/visitor-log/change-how-long-visitor-logs-are-kept/) [View all 2 articles](/docs/visitor-log/) ## [Security Fixes](/docs/security-fixes/) 11 * [Security Headers](/docs/security-fixes/security-headers/) * [Secure Cookies](/docs/security-fixes/secure-cookies/) * [Disable plugin & theme editor](/docs/security-fixes/disable-plugin-theme-editor/) * [Disable WP Sitemaps](/docs/security-fixes/disable-wp-sitemaps/) * [Disabling the Application Passwords Feature in WordPress 5.6](/docs/security-fixes/disable-application-passwords/) * [Preventing Username Enumeration on Your WordPress Site](/docs/security-fixes/disable-username-enumeration/) * [Remove unwanted files](/docs/security-fixes/remove-unwanted-files/) * [Hide WP Version](/docs/security-fixes/hide-wp-version/) * [Hide Windows Live Writer - WLW](/docs/security-fixes/hide-windows-live-writer-wlw/) * [Hiding PHP Version by Removing "X-Powered-By" and "Server" Headers](/docs/security-fixes/hide-php-version/) * [Content Security Policy](/docs/security-fixes/content-security-policy/) [View all 11 articles](/docs/security-fixes/) ## [Core Scanner](/docs/core-scanner/) 3 * [Core Scanner](/docs/core-scanner/core-scanner/) * [Scan WordPress](/docs/core-scanner/scan-wordpress/) * [How to ignore files](/docs/core-scanner/how-to-ignore-files/) [View all 3 articles](/docs/core-scanner/) ## [Malware Scanner](/docs/malware-scanner/) 6 * [Malware Scanner](/docs/malware-scanner/malware-scanner/) * [Scan for malware](/docs/malware-scanner/scan-for-malware/) * [False positive results](/docs/malware-scanner/false-positive-results/) * [Whitelist files and folders in Malware Scanner](/docs/malware-scanner/whitelist-files-and-folders-in-malware-scanner/) * [Comprehensive Malware Cleanup Checklist](/docs/malware-scanner/comprehensive-malware-cleanup-checklist/) * [How to exclude paths from the Malware Scanner](/docs/malware-scanner/how-to-exclude-paths-from-the-malware-scanner/) [View all 6 articles](/docs/malware-scanner/) ## [Event Logger](/docs/event-logger/) 6 * [How to use the event logger](/docs/event-logger/how-to-use-the-event-logger/) * [Webhook Events](/docs/event-logger/webhook-events/) * [Automate Alerts: Security Ninja Webhooks via Zapier](/docs/event-logger/integrate-webhooks-with-zapier/) * [Monitoring New Administrator Accounts](/docs/event-logger/monitoring-administrator-accounts/) * [Event Logger Settings](/docs/event-logger/event-logger-settings/) * [How to search and filter events](/docs/event-logger/how-to-search-and-filter-events/) [View all 6 articles](/docs/event-logger/) ## [White label](/docs/whitelabel/) 2 * [What is the White label feature](/docs/whitelabel/custom-name-logo/) * [How to white label the plugin](/docs/whitelabel/how-to-whitelabel-the-plugin/) [View all 2 articles](/docs/whitelabel/) ## [Affiliates](/docs/affiliates/) 3 * [Affiliates](/docs/affiliates/affiliate-program/) * [Known Affiliate Link Issues](/docs/affiliates/known-affiliate-link-issues/) * [Branding assets](/docs/affiliates/branding-assets/) [View all 3 articles](/docs/affiliates/) ## [Scheduled Scanner](/docs/scheduled-scanner/) 2 * [Scheduled Scanner](/docs/scheduled-scanner/scheduled-scanner/) * [Add custom schedule to scanner](/docs/scheduled-scanner/add-custom-schedule-to-scanner/) [View all 2 articles](/docs/scheduled-scanner/) ### Maximizing Your Security with WP Security Ninja As you explore the extensive resources within our documentation, we hope you've found valuable insights and answers to enhance your WordPress site's security. WP Security Ninja is designed to empower you, providing not just tools, but also the knowledge to use them effectively in your quest to protect your site. Security is a journey, not a destination. As WordPress continues to evolve, so do the threats that target it. That’s why we continuously update our plugin and resources to tackle the latest security challenges. Keep your site and your knowledge up to date by revisiting our documentation and utilizing the latest features and best practices provided. #### Engage with Our Community Join the WP Security Ninja community to share experiences, tips, and insights with other WordPress users. Engage with us and the community on social media, forums, and through our support channels. Your feedback not only helps us improve but also shapes the future of WP Security Ninja. #### We're Here to Help If your questions weren't answered in our documentation or you're facing issues that require a more personalized approach, don't hesitate to reach out. Our dedicated support team is ready to assist you with any queries, concerns, or feedback you might have. Contact us through our support page, and let us help you secure your site effectively. #### Stay Updated For the latest updates, security tips, and WP Security Ninja news, subscribe to our newsletter. Stay ahead of threats by being the first to know about our latest features, updates, and best practices. #### Thank You for Trusting WP Security Ninja We appreciate your trust in WP Security Ninja to secure your WordPress site. Our team is committed to providing you with the best tools and support to keep your site safe. Thank you for choosing WP Security Ninja, and here's to a secure online presence! --- ## Firewall Guides for the free 8G request firewall, Pro Cloud Firewall (600M+ bad IPs), login protection, country blocking, and 2FA. * ### [How to use the firewall](/docs/firewall/how-to-use-the-firewall/) * ### [Block IP Network (global bad IPs)](/docs/firewall/block-ip-network/) * ### [8G Firewall Rules](/docs/firewall/8g-firewall-rules/) * ### [How to get back into your website](/docs/firewall/how-to-get-back-in-to-your-website/) * ### [Restore access without the unblock URL](/docs/firewall/how-to-restore-access-without-the-unblock-url/) * ### [Secret Access URL](/docs/firewall/secret-access-url/) * ### [Change login URL](/docs/firewall/change-login-url/) * ### [Login form protection](/docs/firewall/login-form-protection/) * ### [Block or redirect visitors](/docs/firewall/block-or-redirect-visitors/) * ### [How to block a country](/docs/firewall/how-to-block-a-country/) * ### [How to blacklist an IP](/docs/firewall/how-to-blacklist-an-ip/) * ### [Ban subnet / IP range](/docs/firewall/ban-subnet-mask/) * ### [Whitelisting services](/docs/firewall/whitelisting-services-in-wp-security-ninja/) * ### [Automatically validated crawlers](/docs/firewall/automatically-validated-crawlers/) * ### [404 Guard](/docs/firewall/404-guard/) * ### [WooCommerce rate limits & coupon protection](/docs/firewall/woocommerce-rate-coupon-protection/) * ### [Set up 2FA (admin)](/docs/firewall/how-to-set-up-two-factor-authentication-2fa-in-security-ninja/) * ### [Use 2FA (users)](/docs/firewall/setting-up-and-using-two-factor-authentication-2fa-for-users/) * ### [Allow users to bypass 2FA](/docs/firewall/how-to-allow-users-to-bypass-2fa-in-security-ninja/) * ### [Reset 2FA](/docs/firewall/how-to-reset-2fa/) * ### [Cannot import data](/docs/firewall/cannot-import-data/) --- ## Install: Quick Start Guide ## Install the plugin **To install the free plugin from inside WordPress admin. the easiest way** 1. Visit ‘Plugins > Add New’ 2. Search for ‘Security Ninja’ 3. Activate Security Ninja from your Plugins page. ### To install the free or premium plugin manually via FTP 1. Download the latest version from WordPress.org. [https://downloads.wordpress.org/plugin/security-ninja.zip](https://downloads.wordpress.org/plugin/security-ninja.zip) 2. Unpack the.zip file to a folder on your computer. 3. Upload the \`security-ninja\` folder to the \`/wp-content/plugins/\` directory 4. Activate the Security Ninja plugin through the ‘Plugins’ menu in WordPress ### To install the free or premium plugin via “Upload plugin” You can also install the plugin via upload from inside WordPress admin. It requires you have downloaded the free or premium plugin in.zip format locally to your computer. 1. Visit ‘Plugins > Add New’ 2. Choose “Upload plugin” and find the.zip file containing the plugin. 3. Active the Security Ninja plugin ## Activate Pro Version ![Activate Security Ninja Pro from the Plugins page](/media/2019/07/how-to-activate-security-ninja-pro-plugin.webp) After you click activate, you will be asked to enter your license key. ![Enter your license key, includes the “Can’t find your license key?” link](/media/2020/07/enter-license-key.webp) If you cannot locate the license key, please check your email inbox or use the “Can’t find your license key” link right below the License key input field. This will open a small window where you can enter your email to get the license key sent to your inbox. ![Send license key window, enter your email to resend the key](/media/2020/09/resend-license-key.webp) Once you have finished and the license key has been validated you will be directed to the plugin page. ## Upgrading from the old system. Gumroad > If you already had an old version of Security Ninja installed, the plugin will try to detect the license from the old system and automatically create a new license for you, bypassing this screen. If you do see the screen and you need to get a license, here is what you do: 1\. Use the button in the bottom “Activate Free Version.” This will create a license for you, and register your email in the system. 2\. Contact us with a license upgrade request, and we can manually update or create a new license for you to use. Click here: [https://wpsecurityninja.com/help/](/help/) _Important: You have to “Activate Free Version” to create a user in the licensing system before we can create a custom license manually._ * * * ### Activate License If you already installed a Free version you can upgrade the License by going to Security Ninja -> Account and click the Activate License button. ![Account Details, click Activate License](/media/2019/07/activate-license.webp) This will open a popup where you can enter the Pro license key. ![Update License popup with license key field](/media/2020/06/update-license-enter-license-key.webp) --- ## WordPress Security Guide 2026: Where to Start You do not need another 15,000-word “ultimate” guide that repeats the same advice five times. You need a clear order of work and links to guides that already go deep. Use this page as the map. ![WordPress Security Guide](/media/2025/08/WordPress-Security-Guide.webp) ## Why WordPress security still matters WordPress runs a huge share of the web, so bots test the same login and plugin paths constantly. A compromise is rarely “just a defaced homepage.” Typical fallout includes: - Stolen customer or form data - Spam and malware served to your visitors - Search Console security warnings and ranking damage ([SEO recovery after a hack](/recover-wordpress-websites-seo-after-hacker-attack/)) - Hosting suspensions after your site is used to attack others - Lost trust when clients or shoppers see browser warnings You do not need to fear WordPress as a platform. You do need maintenance: updates, fewer plugins, locked logins, scans, and backups you can restore. The sections below point to the deep guides for each job. ## How to use this hub 1. Start where you are (beginner, hardening, incident, or store) 2. Do the linked guide for that step 3. Come back for the next layer 4. Install tooling that matches the jobs you will actually run Security Ninja covers tests, vulnerability checks, and (on Pro) firewall, malware scanning, and login protection. Details live in the linked feature and comparison posts, not in another pasted essay here. ## 1. Beginners and a working checklist If you are new or inherited a messy site, start here: - [WordPress security beginners guide](/wordpress-security-beginners-guide/) - [WordPress security checklist](/wordpress-security-checklist/) - [Do I need a WordPress security plugin?](/do-i-need-a-wordpress-security-plugin/) Goal: backups you can restore, updates applied, unused plugins gone, admin accounts under control. ## 2. Best practices and hardening Once the basics are steady, raise the floor: - [WordPress security best practices](/wordpress-security-best-practices/) - [WordPress security hardening guide](/wordpress-security-hardening-guide/) - [Common WordPress security mistakes](/common-wordpress-security-mistakes/) - [Top WordPress security issues](/wordpress-security-issues/) Goal: fewer soft defaults, clearer roles, less unnecessary attack surface. ## 3. Login, passwords, and 2FA Most opportunistic attacks still start at wp-login and weak credentials: - [WordPress login security complete guide](/wordpress-login-security-complete-guide/) - [Two-factor authentication (2FA)](/two-factor-authentication-2fa/) - [Top WordPress passwords](/top-wordpress-passwords/) Goal: strong unique passwords, 2FA on admins, rate limits / lockouts when abuse shows up. ## 4. Firewall and scanners Protection and detection are different jobs. You usually want both: - [WordPress firewall plugins guide](/wordpress-firewall-plugins-guide/) - [WordPress security scanner comparison](/wordpress-security-scanner-comparison/) - [WordPress vulnerabilities hub](/wordpress-vulnerabilities-database/) - [Do security plugins slow WordPress down?](/do-security-plugins-slow-down-wordpress/) - Feature pages: [vulnerabilities](/vulnerabilities/), [core scanner](/core-scanner/), [malware scanner](/malware-scanner/), [cloud firewall](/cloud-firewall/) Goal: block known-bad traffic, catch vulnerable versions, notice bad files on a schedule. ## 5. Malware removal and recovery If the site is already weird (spam, redirects, unknown admins, locked hosting): - [Signs your WordPress site is hacked](/signs-wordpress-site-is-hacked/) - [What to do if your WordPress site is hacked](/what-should-you-do-if-your-wordpress-site-is-hacked/) - [WordPress malware removal](/wordpress-malware-removal/) - [Create a backup plan](/create-backup-plan-if-site-gets-attacked/) - [Hire cleanup](/consultation/) when you need hands on the server Goal: contain, clean or restore, rotate credentials, close the entry point, then harden so it does not return. ## 6. WooCommerce and stores Stores add checkout, coupons, and payment noise: - [WooCommerce security guide](/woocommerce-security-guide/) Goal: rate limits where abuse hits, fewer junk plugins, faster response to vuln notices on commerce extensions. ## 7. Free vs Pro and pricing Match spend to jobs: - [Do I need a WordPress security plugin?](/do-i-need-a-wordpress-security-plugin/) - [Free vs premium security plugins](/free-vs-premium-security-plugins/) - [Best WordPress security plugins](/best-wordpress-security-plugins/) - [Do security plugins slow WordPress down?](/do-security-plugins-slow-down-wordpress/) - [Pricing](/pricing/) - Free on [WordPress.org](https://wordpress.org/plugins/security-ninja/) Rough map: Free gets 50+ tests, vulnerability scanning, and core integrity. Pro adds Cloud Firewall (600M+ bad IPs), malware scanning with schedules, login protection and 2FA, WooCommerce limits, and agency-friendly options. ## Suggested order for a healthy site | Stage | Focus | Primary links | | --- | --- | --- | | Week 1 | Checklist, backups, updates | Beginners, checklist | | Week 2 | Login + 2FA | Login guide, 2FA | | Week 3 | Scan + firewall | Scanner comparison, firewall guide | | Ongoing | Patch vulns, review findings | Vulnerabilities hub, best practices | | If hacked | Contain and clean | Malware removal, consultation | ## CMS choice (only if you are deciding platforms) Already on WordPress? Stay and harden. Comparing CMSs for a new project? [Drupal vs WordPress security](/wordpress-vs-drupal/) is a balanced take. Switching platforms just to “feel safer” usually delays the maintenance work that actually matters. ## Related reading - [WordPress security beginners guide](/wordpress-security-beginners-guide/) - [WordPress security checklist](/wordpress-security-checklist/) - [WordPress security hardening guide](/wordpress-security-hardening-guide/) - [WordPress login security guide](/wordpress-login-security-complete-guide/) - [WordPress firewall plugins guide](/wordpress-firewall-plugins-guide/) - [WordPress malware removal](/wordpress-malware-removal/) ## Bottom line Secure WordPress is a maintenance habit: update, reduce plugins, lock logins, scan, firewall, restore-tested backups. Use this hub to pick the next deep guide, then do the work. When you want the tooling in one plugin, start free or move to Pro on [pricing](/pricing/). --- ## WordPress Security for Agencies --- ## WordPress Security Features That Protect Your Site