We've spent the last few weeks trying to break our own plugin. We fuzzed the WebAuthn decoder with 200,000 adversarial inputs, found a bug where brute-force lockout could silently lock out every legitimate visitor sharing a CDN's IP, and once we went looking, found and fixed six separate places in the codebase making that same mistake. All of it is documented, versioned, and dated: https://secondgatewp.com/security-testing-methodology/
SecondGate is built local-first: no Composer dependencies, no third-party WebAuthn library, and nothing about your visitors is ever sent anywhere. All matching – country, IP, bot verification – happens on your own server against locally cached data. To be upfront about the outbound calls that do exist: Pro downloads curated IP blocklists for Microsoft Azure, DigitalOcean, Hetzner, and OVH on a schedule, and the vulnerability scanner checks your installed plugin/theme names against a public vuln database. That's data coming in, and software names going out – never anything about your visitors or their traffic.
Now we want 100 technical testers, free full Pro access, to find what we haven't.
What's actually been tested, not just built:
Passkey/WebAuthn support with a custom CBOR decoder, checked against official RFC 8949 conformance vectors, real authenticator-captured data, and 200,000 fuzzed adversarial inputs.
Country/IP blocking running on locally cached range data – no external lookups per visitor.
Phantom decoy records: no legitimate path reaches them, so a hit is a strong signal someone's enumerating your site.
Behavioral login-cadence sliding-window rate limiting.
Token-chained audit logs designed to survive administrative compromise.
wp-config.php kill switches that persist consistently across every bootstrap path.
What we're honest about not having finished: the blocking paths that can actually lock someone out don't have real end-to-end regression tests yet. Several of the signal and logging paths are code-reviewed, but not yet automated.
What we are looking for: developers, agency owners, and sysadmins running custom WordPress stacks or client sites who will actually push on edge cases, not just install and forget. Real findings go straight back into the methodology page, with your input credited if you want it.
Top comments (2)
No-cloud passkeys for WordPress is a strong trust angle if the setup path stays understandable. Technical testers will probably stress the edge cases first: account recovery, lost device flow, multisite behavior, plugin conflicts, and whether admins can prove no external dependency is being introduced.
Alex, that's a fair read of where testers will actually go. Here's where each of those stands:
Account recovery / lost device. Already covered. Backup codes use a slow hash (wp_hash_password), specifically because they're short enough to type by hand, so a fast hash would be the weak point. Trusted devices only ever store a hash of the token, never the plaintext, and it's one click to forget a device.
No external dependency. This one's checkable, not a claim. No third-party accounts anywhere in the free plugin. License validation is fully offline, RSA-signed and verified locally, same primitive as the passkey signature check. Crawler verification is DNS-based. Threat-intel data is downloaded and matched locally. It's all in the source.
Multisite. Tested against a real multisite network (real MariaDB, real WP core, two real sites), network-activated, with the actual settings page rendered in a real admin context on both sites. Clean render, zero fatal errors, and settings and license state stay isolated per site, verified rather than assumed. The real limitation: there's no network-wide settings panel yet, so each site in a network needs configuring individually for now.
Plugin conflicts. Checked at the source level. Everything's properly namespaced, no bare global functions anywhere, so collision risk with other plugins is low. Live testing against specific other plugins is still open.
The setup path staying understandable is a fair separate point too, that's more something you find out by watching real non-technical users go through it than something I can just tell you is fine.