Vulnerability Disclosure Policy

Send the report to solutions@expandware.com with "security" in the subject line, so it is routed rather than queued behind commercial enquiries. This is the address the whole site publishes and it is read every business day, which matters more for a disclosure route than a dedicated one nobody has checked since it was created.

Please report in English. We would rather have a rough description in a language we can read today than a polished one we have to translate.

What to include

• Where. The URL, endpoint, or parameter affected, and the date and time you tested.
• What. What you found, and what an attacker could do with it. An impact you can describe in one sentence is worth more than a severity score.
• How. The steps to reproduce it. A short proof of concept, a request and response pair, or a screenshot is usually enough.
• Who. How you would like to be credited, or that you would prefer not to be. Both are fine.

This policy covers expandware.com, its subdomains, and the services this website runs on: the contact form, the newsletter, the search endpoint, and the content management system behind the editorial sections.

Out of scope

Systems we operate for a client are the client's, not ours, and are not covered here. If you believe you have found something in one of those, tell us and we will route it to the organization that owns it rather than acting on it ourselves.

• Third party services this site depends on. Report those to the vendor: their disclosure programs are better resourced than ours and they own the fix.
• Findings from an automated scanner with no demonstrated impact, including a missing header that no attack depends on, or a version number in a response.
• Reports that require an attacker to already control the reader's device, browser, or network.
• Social engineering of our staff or our suppliers, and anything physical.

Test only against your own data. If you reach personal data belonging to somebody else, stop at the point you have proved the flaw exists, do not download or retain it, and say so in the report.

• Do not degrade the service. No denial of service, no load testing, and no automated scanning heavy enough to affect other people using the site.
• Do not modify or delete data that is not yours, and do not use one finding as a foothold to look for another.
• Give us a reasonable opportunity to respond before disclosing publicly. If you intend to publish, tell us when, and we will work to your timetable rather than argue about it.

• Acknowledgement. We will confirm we have received your report within five business days.
• An honest assessment. We will tell you whether we consider it a vulnerability, and if we do not, why. A disagreement is a better outcome than silence.
• Progress. Where we accept a report, we will keep you informed until it is resolved.
• Credit. We will credit you if you want it, in whatever name you give us.

What we do not offer

There is no bug bounty and no monetary reward. We would rather say so plainly than have you spend an afternoon on the assumption that there is one.

If you follow this policy, we will treat your research as authorized conduct, we will not pursue or support legal action against you for it, and we will say so to anyone who asks.

This is our commitment and only ours. It cannot waive the rights of a third party, and it does not bind a supplier whose systems you reach through ours, which is why the scope section asks you to stay inside what we actually operate.

The same contact details are published at /.well-known/security.txt in the format defined by RFC 9116, which is where automated tooling looks. That file carries an expiry date, and this site fails its own build if the date is close enough to be misleading.