snapme

Supported Versions

Only the latest 0.1.x release line is supported with security fixes. Older commits, unreleased tags, and historical branches are not supported.

Version	Supported
0.1.x	Yes
< 0.1.0	No

Reporting a Vulnerability

Report a suspected vulnerability privately, through GitHub Security Advisories:

https://github.com/ikhsanddy/snapme/security/advisories/new

Please do not open a public issue, discussion, or pull request for a security problem. If you cannot use advisories, open an issue that only asks for a private contact channel, without any detail of the finding.

Include what you can of the following:

• What the problem is and what an attacker could do with it.
• Reproduction steps, or a minimal proof of concept.
• Which part is affected: a page, an API stub under src/app/api, or a module in src/lib or src/features.
• Any proposed fix.

Response Expectations

This is a small project without a service level agreement. Reports are read and answered on a best effort basis. A confirmed issue is fixed on the supported branch and noted in the release. Please give the maintainer a reasonable window to ship a fix before publishing details.

Scope

In Scope

• The client app itself: anything that causes an image, clip, or identifier to leave the device, or that weakens the guarantee that capture, editing, and export run locally
• The security headers in next.config.ts: the CSP (which must stay free of external hosts), Permissions-Policy, and the noindex and no-referrer rules on /s/* and /r/*
• The API stubs under src/app/api: they must keep answering the constant 503 contract and must never start accepting or storing data without a new security review
• Secrets that reach the repository or a shipped bundle

Out of Scope

• Vulnerabilities in third-party dependencies: report those upstream. If a dependency issue affects snapme's behavior, a private report is still welcome.
• Forks, modified deployments, and self-hosted instances.
• Denial of service, load testing, and brute force. There is no hosted instance to attack.
• Attacks that require physical access to an unlocked device, or social engineering.
• The camera, gesture model, and export paths, which never leave the device: anything an attacker can already read on the device itself is not a vulnerability here.

Secrets

No credential, token, or private key is stored in this repository, and the app needs none: there are no environment variables for the build or at runtime.

• The former runtime secrets and their .example templates were removed together with the backend. If a change reintroduces a credential, it must be read from the environment and documented in this section; it must never be committed.
• Session and delete tokens are generated on the user's device and stay there; nothing about them reaches a server, because there is no server.

If you find a credential in the repository or in its history, treat it as compromised: report it privately, rotate it with its provider, then open a pull request that removes it and records the rotation in docs/DECISIONS.md.