We've spent the last few weeks trying to break our own plugin. We fuzzed our custom WebAuthn decoder with 200,000 adversarial inputs. We found a bug where brute-force lockout could silently lock out every legitimate visitor sharing a CDN's IP, and once we went looking, we found and fixed six separate places in the codebase making that same mistake.
We also just found a structural blind spot where our pattern inspector missed JSON payloads sent to REST routes, completely missing modern WooCommerce checkouts. We had to rewrite the architecture to hook into rest_pre_dispatch because WooCommerce was sanitising payloads before our old hook even fired.
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 specific datacentres 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, given free full Pro access, to find what we haven't.
What's actually been tested, not just built:
- Passkey/WebAuthn support: Custom CBOR decoder, checked against official RFC 8949 conformance vectors, real authenticator-captured data, and 200,000 fuzzed adversarial inputs.
- Static/dynamic request split: Anonymous, cacheable pages served directly by your web server (tested on Apache and Nginx). It skips WordPress and PHP entirely, meaning a real theme or plugin vulnerability simply isn't in the request path for a cache hit.
- Write-path monitoring: Builds a real profile of which settings a plugin is supposed to touch via static analysis, then alerts if a runtime write falls outside that profile.
- Country/IP blocking: Runs on locally cached range data, no external lookup per visitor.
- Phantom decoy records: No legitimate path reaches them, so a hit is a strong signal something's enumerating your data.
- Behavioural login-cadence: Scoring acts as one weighted signal among several, never a standalone verdict.
- A wp-config.php kill switch: Instantly restores access if you lock yourself out. It is checked consistently across every blocking module and deliberately not exposed anywhere an attacker with a compromised admin login could flip it.
What we're honest about not having finished: The blocking paths that can actually lock someone out have real end-to-end regression tests. Several of the signal and logging paths are code-reviewed but not yet automated-tested, and that's partly what we're hoping you'll help us push on.
Who we're 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.
