Security

Ambikly security and how to report a vulnerability.

A commerce plugin handles money, downloads and personal data, so it is held to a higher standard than a slider. This page says how the plugins are built, what we ask of researchers, and what we promise back.

Private reports, acknowledged next business day Safe harbor for good-faith research Credit in the release notes if you want it
Reporting

Four steps from finding to fix.

  1. Email us privately

    Write to [email protected] with “Security:” at the start of the subject. Please do not open a public issue, post a proof of concept or contact customers first.

  2. Include what reproduces it

    Plugin and Pro versions, the add-on or screen involved, the role you were using, the request or steps, and what you observed. A minimal proof of concept is welcome; live customer data is not.

  3. We confirm, triage and fix

    You get a receipt on the next business day and a severity assessment once we have reproduced it. Fixes ship as a patch release of the affected plugin, with the release notes describing the issue once most stores have updated.

  4. Credit, if you like

    Tell us how you want to be named — handle, company or not at all — and that is how the release notes will read.

Scope

What is in scope, and what is not.

TargetIn scopeNotes
Ambikly (free core) — current release Yes REST routes, storefront blocks and shortcodes, checkout, downloads, account area, admin, WP-CLI
Ambikly Pro and all 35 add-ons — current release Yes Including the license client, Addon SDK, ambikly-pro/v1 routes and any add-on storefront surface
ambikly.com and store.ambikly.com Yes This site and the license store; the store runs on Ambikly itself
Older releases Report it We fix forward; if it still reproduces on the current release it is in scope
Denial of service, brute force, spam No Please do not load-test other people’s stores or our servers
Social engineering, phishing, physical access No Out of scope for this policy
Stripe, PayPal, Mailchimp, HubSpot, hosting providers No Report to the provider; tell us if Ambikly’s integration makes it worse
Stores run by Ambikly customers No Only with that store owner’s written permission; the plugin bug itself is in scope
Safe harbor

Good-faith research is welcome.

Ambikly will not pursue legal action or a law-enforcement complaint against researchers who act in good faith under this policy: testing only against systems in scope or their own installation, avoiding privacy violations and data destruction, stopping when they find customer data, and giving us a reasonable time to fix before disclosing. If a third party starts legal action against you for research that followed this policy, we will make it known that you acted with our authorization.

  • Test on your own WordPress install — the free core is a one-minute setup
  • Do not access, modify or keep data that is not yours
  • Do not degrade a live store or our services
  • Give us a chance to ship a fix before publishing
How the plugins are built

The defaults that keep a store honest.

Every route has a permission check

All 186 REST routes declare a permission callback. Store data uses two capabilities, ambikly_manage_store and ambikly_view_store; settings, credentials, webhooks and import/export need manage_options; the few public routes — token-guarded invoices and packing slips, downloads, gateway webhook receivers — verify a token or signature instead.

No card data on your server

Stripe and PayPal handle card entry. An order is marked paid only after a signature-verified webhook or an API confirmation, and off-session charges carry idempotency keys.

Signed webhooks, retried safely

Outbound events are HMAC-SHA256 signed; deliveries retry with backoff and keep a 200-entry log per endpoint so a missed event can be traced, not guessed.

Secrets stay masked

Gateway credentials, webhook secrets and add-on API keys are stored server-side, masked in the admin and in REST responses, and editable only by Administrators.

Atomic writes where money moves

Stock, coupon limits, gift-card balances, store credit and Net Terms credit are changed with single conditional updates, so two checkouts cannot spend the same unit or dollar twice.

Downloads that expire

Digital files are served through tokenized links with per-purchase limits, expiry and IP logging; invoices and packing slips use token-guarded URLs.

Two roles below Administrator

Store Managers change catalog and orders; Support Agents read. Neither can touch settings, credentials, webhooks or import/export, and roles self-heal on each admin load.

GDPR tooling built in

Ambikly registers WordPress personal-data exporters and erasers, so Tools → Export / Erase Personal Data covers customers, orders, addresses and download logs.

Readable, GPL code

Both plugins are GPLv3 with no obfuscation, so the claims on this page can be checked in the source rather than taken on trust. PHPUnit, PHPCS and CI run on every change.

FAQ

Security questions.

Do you pay bounties?

Not at this stage. We do acknowledge every valid report, fix it, name the reporter in the release notes if they wish, and treat good-faith research as exactly that.

How quickly do you respond?

We confirm receipt of a security report on the next business day and tell you what we found and when a fix will ship. Critical issues in payment, license or download handling are fixed ahead of everything else.

Does Ambikly store card numbers?

No. Card and wallet details go directly to Stripe or PayPal; Ambikly receives a payment reference and a signature-verified confirmation. The offline methods — cash, bank transfer, check, manual, Net Terms — involve no card at all.

Are Pro license keys and API secrets visible in the admin?

Secrets in add-on settings are stored server-side and masked in the admin and in REST responses; only Administrators can change them. Store Managers and Support Agents never see payment credentials or webhook secrets.

How do I know a webhook really came from my store?

Every outbound webhook carries an X-Ambikly-Signature header — the string sha256= followed by an HMAC-SHA256 of the raw body with the webhook’s secret. Verify it with a constant-time comparison before trusting the payload; the developer reference shows the code.

What if a vulnerability is in WordPress or a third-party plugin?

Report it to that project. If the interaction with Ambikly makes it worse, tell us too and we will mitigate on our side where we can.

Found something? Tell us first.

One private email, a real reply, a fix in the next patch release.