HolidayOps holds company calendars, API keys and personal data such as email addresses. We take reports seriously and fix confirmed issues quickly.
HolidayOps is pre-launch: releases are v0.x pre-releases until the hosted v1.0.0. Security
fixes go to main and ship in the next release and the next ghcr.io/ahmershahdev/holidayops
image.
| Version | Supported |
|---|---|
main and the latest image |
Yes |
The newest v0.x release |
Yes |
| Older releases | No |
Please don't open a public issue, pull request or discussion for a security problem.
Report it privately, in either of these ways:
- GitHub (preferred): open the Security tab of this repository and choose Report a vulnerability.
- Email: write to support@ahmershah.dev with "Security" in the subject.
Include as much of this as you can:
- the affected endpoint, page or file,
- steps to reproduce, or a proof of concept,
- what an attacker could do with it,
- any logs, requests or screenshots that help.
| When | What |
|---|---|
| Within 7 days | We confirm we received the report and give a first assessment |
| As soon as possible | We fix the issue in a private advisory and keep you updated |
| After the fix ships | We publish the advisory and credit you, unless you prefer to stay anonymous |
If a report turns out not to be a vulnerability, we'll explain why.
In scope:
- the REST API, authentication, sessions and CSRF,
- API keys, quotas and rate limiting,
- organization isolation (any way to read or change another organization's data),
- invites, iCal feed links and digest unsubscribe links,
- webhooks, including server-side request forgery,
- the web app and the public pages (XSS, injection, CSP bypass),
- secrets or personal data exposed in logs, responses or the repository.
Out of scope:
- wrong or missing holiday dates: they come from the holidays library, so report them there or in a normal issue,
- denial of service by sheer traffic volume,
- findings from automated scanners without a demonstrated impact,
- missing best-practice headers that don't lead to an exploit,
- social engineering, and attacks that need physical access to a device.
We won't take action against good-faith research that follows this policy. While testing:
- use your own accounts and organizations, and never access or change other people's data,
- don't degrade the service for others,
- give us reasonable time to fix an issue before you disclose it.
The design is documented in docs/security.md: Argon2 passwords, hashed API keys
and tokens, authenticator and webhook secrets encrypted at rest, two-factor sign-in, sign-up and
reset that never reveal whether an address is registered, tenant isolation tested on every
endpoint, per-IP, per-key and per-organization rate limits, an SSRF guard for webhooks, a strict
Content Security Policy, and exact-pinned dependencies checked by Dependabot, pip-audit and CodeQL.
Before each release, scripts/attack_simulation.py runs against the production image.