Security & vulnerability disclosure

Email [email protected]. Please include enough detail for us to reproduce the issue — the affected URL or screen, the steps you took, and what you observed. A proof-of-concept, screenshot, or short screen recording helps a great deal.

Please report privately and give us a chance to fix the issue before disclosing it publicly. We do not run a paid bug-bounty programme, and we will not offer a monetary reward — but we will credit you by name in the fix notes if you would like us to.

• We aim to acknowledge your report within 5 business days.
• We will give you an assessment and a rough remediation timeline within 10 business days of acknowledging it.
• We will tell you when the issue is fixed, and confirm if you would like to re-test.
• We will not pursue legal action against you for research conducted in good faith under the rules below.

NeoKaam is built by a very small team. These are honest targets rather than a contractual SLA, and complex issues may take longer to fix — but we will keep you informed rather than going quiet.

We consider security research conducted in accordance with this policy to be authorised access. If you follow the rules below in good faith, we will not report you to law enforcement or bring a civil claim against you in connection with your research. If a third party brings action against you for research that complied with this policy, we will make it known that your actions were authorised.

This safe harbour applies only to the extent permitted by applicable law, and does not extend to actions that intentionally harm our users or their data.

• Use only accounts you own or have explicit permission to test. Register a free account rather than testing against someone else's.
• Do not access, modify, delete, or exfiltrate data belonging to other users. If you encounter someone else's data, stop, and tell us what you saw without keeping a copy.
• Do not run automated scanners, load tests, or brute-force attacks against our production systems — they degrade the service for real users.
• Do not use social engineering, phishing, or physical attacks against our staff, users, or infrastructure providers.
• Do not deface, disrupt, or degrade the service in any way.

• The web application at tickbox.work and neokaam.com
• The Tickbox and NeoKaam mobile applications (iOS and Android)
• The public API served under those domains

The following are already known to us or are not things we will act on:

• Findings from automated scanners without a demonstrated, working exploit — including generic dependency-version reports.
• Missing security headers, cookie flags, or TLS configuration weaknesses with no demonstrated impact.
• Rate-limiting or brute-force concerns on endpoints that are not authentication-related.
• Self-XSS, clickjacking on pages with no sensitive action, and issues that require an already-compromised device or browser.
• Email spoofing, SPF/DKIM/DMARC configuration, and mail-delivery concerns.
• Vulnerabilities in third-party services we consume, which should be reported to them.
• Denial of service, resource exhaustion, and volumetric attacks.

The same contact details are published in /.well-known/security.txt per RFC 9116.