Vulnerability disclosure policy

1. Scope

This policy applies to the following assets:

• modularciso.com — The primary web application, including all subpaths
• API endpoints — All /api/* routes served by our backend
• Authentication system — Login, registration, session management, OAuth flows
• Payment integration — Gumroad webhook processing and subscription verification

Out of scope

• Third-party services we use (Cloudflare, Gumroad, Resend) — report to them directly
• Social engineering or phishing attacks against modularCISO staff
• Denial-of-service (DoS/DDoS) attacks
• Automated scanning that degrades service availability
• Physical security testing

2. How to report

Send your report via encrypted email to:

Email: contact@modularciso.com

PGP key: Download our PGP public key

Your report should include:

1. Description of the vulnerability and its potential impact
2. Steps to reproduce — Clear, step-by-step instructions
3. Proof of concept — Screenshots, HTTP requests/responses, or scripts (if applicable)
4. Affected URL or endpoint
5. Your contact information — So we can follow up with questions

3. What we commit to

• Acknowledgement within 48 hours of receiving your report
• Initial assessment within 5 business days
• Regular updates on the status of your report until resolution
• Credit on our Security Acknowledgements page (unless you prefer anonymity)
• No legal action against researchers who follow this policy

4. Rewards

modularCISO does not operate a paid bug bounty programme. We do not offer monetary compensation for vulnerability reports. Researchers who report valid issues in accordance with this policy will be credited on our Security Acknowledgements page (unless anonymity is preferred).

5. What we ask of you

• Report promptly — Notify us as soon as you discover a vulnerability
• Don't exploit — Do not access, modify, or delete data belonging to other users
• Don't disclose publicly — Give us reasonable time (90 days) to fix the issue before any public disclosure
• Minimise impact — Use the minimum actions necessary to demonstrate the vulnerability
• Don't use automated tools at high volume against production systems
• Create test accounts using your own email — Do not target accounts belonging to real users

6. Qualifying vulnerabilities

We are particularly interested in:

• Authentication or session management flaws
• Authorization bypasses (e.g., reaching gated lesson content or another user’s saved work without authenticating)
• Cross-site scripting (XSS), including stored XSS
• Cross-site request forgery (CSRF)
• SQL injection or NoSQL injection
• Server-side request forgery (SSRF)
• Insecure direct object references (IDOR)
• Information disclosure (credentials, PII, internal paths)
• Flaws in the content access gate, watermarking, or the GDPR export and deletion flows

Non-qualifying issues

• Missing HTTP headers that don't lead to exploitable vulnerabilities
• Self-XSS (issues only exploitable by the victim against themselves)
• Missing rate limiting (unless it leads to a concrete exploit)
• Software version disclosure
• Issues in third-party dependencies without a demonstrated exploit path
• Best-practice suggestions without a security impact

7. Known accepted constraints

These are real weaknesses. We know about them, we can explain why they are still here, and a report telling us they exist will be acknowledged but not treated as a new finding. A report showing one of them is exploitable in practice very much is a finding.

Content-Security-Policy allows 'unsafe-inline' for scripts

This weakens our CSP's main protection against injected scripts, and on a site that teaches CSP it is a fair thing to point at. It is still there because Cloudflare's bot-management platform injects an inline script into every page:

window.__CF$cv$params={r:'<per-request token>', ...};
(function(){ ... '/cdn-cgi/challenge-platform/scripts/precursor/main.js' ... })();

That script carries a token which changes on every response, so it cannot be allowlisted by hash, and Cloudflare does not stamp its own injection with a nonce we generate. Removing 'unsafe-inline' would block it on every page load — disabling JS-based bot detection and filling the console with violations — so the honest options are to keep the allowance or to turn off bot mitigation. We have chosen to keep bot mitigation.

What we control, we are working on: our own pages contribute a small number of inline scripts, and the tool pages use inline event handlers, some generated dynamically. If the platform stops requiring an inline script, or we move off it, the allowance goes with it.

PBKDF2 at 100,000 iterations

Below current OWASP guidance. 100,000 is the maximum the Cloudflare Workers runtime accepts for PBKDF2 through the Web Crypto API — it is a platform ceiling, not a work factor we chose. See the Privacy Policy for the full note.

No multi-factor authentication yet

Accounts are password-only. The password minimum is 14 characters, which is what CIS Controls v8.1 Safeguard 5.2 asks for on accounts without MFA. MFA is the correct fix and is not yet built.

8. Legal safe harbour

If you conduct security research in compliance with this policy, we will consider your research to be authorised. We will not initiate legal action against you for your research activities. If legal action is initiated by a third party against you in connection with research conducted under this policy, we will make this authorisation known.

9. Contact

For questions about this policy or to submit a vulnerability report:

Email: contact@modularciso.com

PGP key: /.well-known/pgp-key.txt