Reporting
Tell us about a vulnerability
Write to security@polksec.com. A human reads it. Please include enough to reproduce the issue, and tell us whether you would like to be credited.
Scope
What to test, and what not to
In scope
The Polksec application at app.polksec.com, the public pages at
polksec.com, and the authentication and isolation model described
below. Given what this product does, the finding we most want to hear about is any way for one
customer to reach, infer or affect another customer's data.
Not in scope
Cloudflare's own infrastructure — assume it behaves as documented. Denial of service and volumetric testing. Physical, endpoint, or social engineering. Third-party dependencies, which are tracked separately.
Please do not
Access, modify or delete data belonging to a customer who is not you. Use a finding to extract data rather than to demonstrate it. Test against a customer's own portal hostname without that customer's permission — their trust portal is theirs, not ours.
How it is built
The claims this product makes about itself
Stated as properties rather than reassurances, because a security page is worth exactly as much as the specificity in it.
One customer cannot see another's evidence
Each customer's content lives in its own database, so a query that lost its tenant filter returns nothing rather than somebody else's documents. Tenant identity comes from the hostname or the server-side session and never from anything the caller supplies. A release-blocking isolation suite attacks these boundaries on every change, and has no skip list.
Documents are encrypted with a key unique to each customer
A per-customer data key, itself wrapped by a key held in a secrets store and never in the database. The customer's identity is bound into the encryption as associated data, so ciphertext moved between customers does not decrypt.
Access decisions are recorded and tamper-evident
Every security-relevant decision is written to a hash-chained, append-only log that the customer can read. Removing or altering an entry breaks every subsequent hash, so tampering is detectable — and if a chain fails verification we tell the customer rather than repairing it quietly.
Support staff cannot read a customer's documents
There is deliberately no super-user. Staff administer accounts and can see lifecycle metadata — status, plan, when an account was created — and there is no view of any customer's documents, control answers or reports. If impersonation is ever added it will be a time-boxed grant the customer can see, not a standing capability.
What is not built, and we will not imply otherwise
Uploaded files are inspected for active content and structural anomalies; this is not antivirus and does not detect malware. There is no rate limiting, which is a known and deliberate gap. Alerting exists and fails visibly, but its delivery destination is not configured on every deployment. The readiness brief we would hand a penetration tester is published with its own list of known weaknesses rather than kept internal.
Disclosure
What happens after a fix
We will agree a disclosure date with you, and we will not publish before it unless a customer is at risk by waiting. If you would like credit, we will name you; if you would rather not be named, we will say that the report came from an external researcher and no more.
Machine-readable contact details are at /.well-known/security.txt.