Security & responsible disclosure

Reporting a vulnerability

Email draftlytic@gmail.com with the details. You don't need to ask permission first or check whether we have a program — just send the report. There's no need to disclose the issue publicly to get our attention.

What to include

• A clear description of the issue and its potential impact.
• The affected URL, endpoint, or page.
• Steps to reproduce, or a proof of concept — enough for us to confirm it.
• Any prerequisites (a specific account state, browser, or configuration).

Scope

This policy covers draftlytic.com and the Draftlytic application and API. Issues in third-party services we use (for example, our payments or email providers) should be reported to those vendors directly, though we're happy to help coordinate where we can.

Good-faith research

If you make a good-faith effort to follow this policy while researching and reporting an issue, we will not pursue legal action against you for that research, and we'll work with you to understand and resolve the issue quickly. To stay within the policy, please:

• Only test against your own account and data — never access, modify, or download another user's data.
• Don't run denial-of-service, load, or brute-force testing, and don't use automated scanners that could degrade the service for others.
• Don't attempt social engineering, phishing, or physical attacks.
• Give us a reasonable amount of time to fix the issue before disclosing it publicly.

Rewards

Draftlytic is a small, independent product and does not run a paid bug bounty program. We can't offer monetary rewards or commit to one in advance. We do read and review every good-faith report, and we're glad to publicly credit researchers who'd like the acknowledgment.

What to expect

We aim to acknowledge valid reports within a few business days, keep you updated as we investigate, and let you know once the issue is resolved. As a one-person operation, timelines can vary — thanks in advance for your patience.

Commonly out of scope

We appreciate the heads-up, but the following generally don't qualify on their own unless you can demonstrate a concrete, exploitable security impact:

• Missing security headers or cookie flags with no demonstrated exploit.
• SPF, DKIM, or DMARC configuration suggestions.
• Reports generated solely by automated scanners, with no validated impact.
• Clickjacking on pages with no sensitive state-changing actions.
• Self-XSS, or issues requiring a fully compromised device.
• Software version disclosure and general best-practice notes.