Get Started

Standard

The trivial plugin gets the same treatment.

Security tends to get applied in proportion to how important a plugin feels. That’s backwards — the forgettable one with a settings page nobody reviewed is the way in. Every Apaxon plugin is checked against the same standard before it ships, whatever it does.

What we check, every release

Authorisation

  • Every action confirms the user holds the capability for it — not just that the menu was visible.
  • Every state-changing request verifies a nonce.
  • Every REST route declares a real permission check. Public read endpoints must justify themselves in a code comment.

Input and output

  • Sanitised on the way in, escaped on the way out. Both, always.
  • Every database statement with a variable in it is parameterised.
  • No user-supplied data is ever deserialised. No dynamic code execution, anywhere.

Files and uploads

  • Uploads validated by real file type, not by extension.
  • Uploaded files stored where they cannot be executed.
  • No plugin accepts a file path from a request and reads or writes it.

Updates and secrets

  • Every release is signed. Unsigned, altered or downgraded packages are refused.
  • Licence keys are stored hashed. We cannot read yours, and neither can anyone who steals our database.
  • Certificate verification is never disabled, for any reason.

Signed releases

HTTPS proves you reached us. It doesn’t prove the file is ours.

A plugin update is remote code that WordPress will unpack and run with full privileges. If someone can substitute that file — through a compromised CDN, a hijacked domain, a proxy on a corporate network — they own every site that installs it.

So every Apaxon release is hashed and signed with a key that never leaves our platform. The matching public key is compiled into the plugin. Before WordPress is allowed to unpack anything, the site checks the signature itself.

If the signature doesn’t verify, the update is discarded — no matter what the connection said, and no matter what our servers claimed.

Algorithm
Ed25519, detached
Signed over
SHA-256 of the package
Verified by
The site, before install
Key location
Compiled into apaxon-core
On failure
Refused

What we haven’t done yet

The gaps, published on purpose.

A security page listing only strengths tells you nothing — every vendor has one. These are ours, and they’ll come off this list as they’re closed.

  • Independent penetration test

    Scheduled before the first paid release. We will publish the summary.

    Open

  • WordPress.org review

    Apaxon Core will go through the directory review process, which is a second pair of eyes.

    Open

  • Bug bounty

    Not yet funded. Responsible disclosure is welcome in the meantime — details below.

    Open

Responsible disclosure

Found something? Tell us.

Email security@apaxon.co.uk with enough detail to reproduce it. We’ll acknowledge within two working days and keep you updated until it’s fixed.

We won’t pursue legal action against anyone reporting in good faith who avoids accessing other people’s data and gives us reasonable time to fix the issue before publishing.