Vulnerability Disclosure
How to report a security issue in WeForm Online, what we promise in return, and the boundaries that keep good-faith research on the right side of the law.
Last updated: 5 August 2026
1. How to report
Email [email protected] with "Security" in the subject, or use the contact form. Please include the affected URL or endpoint, the steps to reproduce, what an attacker gains, and anything you kept (requests, screenshots, IDs) so we can confirm it quickly.
A machine-readable copy of this contact lives at /.well-known/security.txt.
2. What we promise
We confirm receipt within 3 working days and give you an assessment within 10 working days. We keep you updated while we fix it, we tell you when the fix is live, and we credit you by name if you would like that. We will not ask you to sign anything to receive an update, and we will not sit on a report quietly.
3. Safe harbour
If you follow this policy in good faith, we will not pursue or support legal action against you, and we will treat your research as authorised access under the Computer Misuse Act 1990 and equivalent laws. If a third party brings a claim over activity that stayed inside this policy, we will say publicly that it was authorised. Act in good faith, and we will too - if you are unsure whether something is in scope, ask first.
4. In scope
The WeForm Online site and client portal at weformapp.com, and the APIs behind them, including authentication, session handling, access control between customers, document and file access, the e-signature and invoicing tools, and anything that exposes another customer's data.
5. Out of scope
Systems we do not run: our identity-verification, email, DNS/CDN, hosting, review and payment providers. Report those to the provider - we will help you route it if you are not sure who owns what.
Also out of scope as findings on their own, without a working exploit: missing or "weak" HTTP headers, missing SPF/DKIM/DMARC records, self-XSS, clickjacking on pages with no state-changing action, rate limiting on unauthenticated informational endpoints, software version disclosure, and raw output from an automated scanner.
6. Rules of engagement
Never test with real customer data. Use an account you created. The moment you can confirm a vulnerability exists, stop - do not read, copy, alter or keep data that is not yours, do not pivot further into the system, and delete anything you did obtain once you have reported it.
No denial-of-service, stress or load testing. No spam or automated scanning heavy enough to degrade the service for anyone else. No social engineering, phishing or pretexting of our staff, our customers or our suppliers. No physical intrusion. No public disclosure before the fix is live, and no extortion - a report conditioned on payment is not a disclosure.
7. Rewards
We do not run a paid bug bounty at the moment, so please report because it is the right thing to do rather than in expectation of a fee. Serious, well-documented findings are acknowledged publicly if you want the credit, and we will say so in writing for your portfolio.
8. Privacy requests are a different channel
This page is for security vulnerabilities. Access, correction, erasure and other data protection requests are handled under our Privacy Policy, which sets out the contact route and our response times.