Report a vulnerability.

1. Where to send it

Write to hello@democrez.com with subject “SECURITY REPORT”. Include affected URL/feature, issue description, reproduction steps and contact details. Do not include unnecessary personal data.

If you needed real data to demonstrate the issue, describe it rather than attaching it.

2. The finding that matters most

Stated first because it changes how you should prioritise your time.

Democrez claims that no record links a person to an answer. That claim is what every other claim on this site depends on — deletion, anonymity, what an institution cannot obtain, what a court could not compel. Anything that breaks it, even partially, is the most serious class of finding here.

• Any path from a verification to a response, or the reverse
• Any way to infer an individual's answer from an aggregate, a circle result or an institution report
• Any way to identify participants in a session, or who declined
• Any way to attribute a response through timing, ordering or side channels

Below that, in rough order: authentication and verification bypass, anything permitting one person to answer repeatedly, and anything exposing operational data.

3. In scope

• The Democrez mobile application
• This website and the session environment used for institution sessions
• Backend services these rely on

4. Out of scope

• The Google Fonts request. Already disclosed, and being removed. It is not a finding. Cookie policy
• Missing headers or configuration with no demonstrated impact. Tell us if you like, but it is not a vulnerability report.
• Volumetric denial of service, or anything requiring it. Please do not.
• Social engineering of our people, or physical access attempts.
• Findings in third-party services we use. Report those to their owners; tell us so we can act on our side.
• Design decisions you disagree with. That there is no score, or that answers cannot be withdrawn, is deliberate and explained. Contact

5. What we ask of you

• Report it to us first, and give us a reasonable chance to fix it before publishing.
• Use your own account and your own data. Do not access, alter or retain anybody else's.
• Stop as soon as you have shown the issue exists. Do not go further to see how far it goes.
• Do not degrade the service or affect other people's use of it.
• If you encounter personal data accidentally, stop, tell us, and do not keep a copy.

6. What we commit to

• Acknowledgement target: 2 business days in writing with a reference.
• Initial assessment target: 5 business days. For a validated issue, we provide periodic status updates until remediation.
• Credit: We will credit you publicly if you want it, and not if you do not.
• Safe harbour: Good-faith security research will not be pursued merely for responsible testing where the researcher avoids privacy violations, data destruction, service disruption, extortion, unnecessary data access and public disclosure before a reasonable remediation period.

7. There is no bounty

We do not pay for reports, and saying so plainly is more useful than leaving it ambiguous. This is a small team without a security budget, and a bounty programme we could not fund properly would be worse than none.

What is on offer is credit, a real reply from somebody who understands the report, and a fix. If that is not worth your time, we understand.

8. Publishing your findings

We will not ask you to stay quiet indefinitely. Once an issue is fixed, or once it is clear we are not going to fix it, publish what you like — including that we were slow, if we were.

What we ask is that you do not publish before a fix in a way that puts people's data at risk in the meantime.

9. If we handle this badly

Raise it with the Grievance Officer, who is independent of whoever handled the report. Grievance redressal

This policy sits alongside the terms of service. Effective date: 11 September 2026.