Security & Responsible Disclosure

1. How to report

Email support@profscann.com with "Security" in the subject line.

Helpful things to include:

• What the issue is and roughly how serious you think it is.
• Steps to reproduce it — a URL, a request, a short script. Enough that we can see it ourselves.
• What an attacker could actually achieve with it.
• Whether you have told anyone else, or intend to.

Write in whatever detail you have. A rough report from someone who noticed something odd is far more useful to us than silence.

2. What we promise you

• We will acknowledge your report, normally within 3 working days.
• We will tell you what we found once we have assessed it, including if we decide it is not a vulnerability and why.
• We will keep you updated while we fix it, rather than going quiet.
• We will not take legal action against you, and will not ask your hosting provider or employer to act against you, for research carried out in good faith under this policy.
• We will credit you publicly when the fix ships, if you would like that. We will not name you if you would rather stay anonymous.

We do not currently run a paid bug bounty. We are a free product built by a small operation, and we would rather be honest about that than imply a reward that is not coming. If that changes we will say so here.

3. What we ask of you

• Give us a reasonable chance to fix it before making it public — 90 days is the usual convention, and we will normally be much faster. If we are dragging, tell us and we will give you a date.
• Use your own accounts and your own test data. Register a second account if you need two.
• Do not access, modify or delete data belonging to anyone else. If you can prove a vulnerability without touching real data, do it that way. If you accidentally access someone else's data, stop, and tell us what you saw so we can assess the exposure.
• Do not degrade the service. No denial-of-service testing, no automated scanning at volume, no spam or brute-force floods against live endpoints.
• Do not use social engineering against us, our users, or our suppliers. No phishing, no pretexting, no physical intrusion.
• Do not extort. Reports conditioned on payment, or threats to publish unless paid, are not good-faith research and this policy will not protect them.

4. In scope

• profscann.com and its subdomains
• The Profscann web application, including the API endpoints used by the server agent and Sentinel
• The guard code Sentinel generates, and the agent install script

Out of scope

Third-party services we use but do not control — our host, our email provider, Meta's pixel, and so on. Please report those to the provider directly.

We also generally will not treat the following as vulnerabilities, though we are happy to hear about them:

• Missing security headers with no demonstrated exploit.
• Our Content-Security-Policy allowing unsafe-inline / unsafe-eval. We know. Alpine.js requires it, and the reasoning is documented in our code.
• Reports produced purely by an automated scanner with no manual verification.
• Missing rate limits without a demonstrated impact.
• Self-XSS, or issues requiring a fully compromised browser or physical device access.
• Anything about the Sentinel site key being visible in customer source code. It is public by design and grants nothing but the ability to file an event.

5. If you are a Profscann user reporting something about your own account

If you think your account has been accessed by someone else, email us immediately and change your password from Account security. Tell us roughly when you noticed and what looked wrong.

6. How we handle a breach of our own

If we suffer a security incident affecting your data, we will:

• tell affected users directly by email, without waiting to have every answer;
• say what happened, what data was involved, and what we are doing about it;
• tell you what you should do — for instance, rotate credentials;
• notify the relevant data protection authority where the law requires it, within the required time.

We will not describe a breach as "an incident affecting a limited number of users" if that is not what it was.

7. Our own security posture

We scan Profscann with Profscann, publicly and regularly. The current report is not hidden — the same checks we run on your site, we run on ours, and when we find something we fix it and say so.

Where a finding on our own site is deliberate — like the CSP one above — we document why in the code rather than suppressing the finding.