Security policy

• useqr.app and www.useqr.app, including every page and static asset.
• The keyless REST API under /api/v1, and the /q shortcut that renders codes from a URL path.
• The MCP server at /api/mcp and every tool it exposes.
• The QR engine and web application source in github.com/rajkaria/useqr.
• The service worker and anything it caches into a visitor's browser.
• The build and release pipeline, including dependency and supply-chain risks with a demonstrated path to our published artefacts.

Worth knowing before you start: there are no accounts, no database, no session and no stored user data anywhere in this system. That removes most of the usual target surface and concentrates what is left. The interesting classes here are server-side request forgery through the endpoints that fetch a URL you supply, injection through URL and query parameters into the rendering pipeline, anything that lets attacker content be served from our origin, and supply-chain compromise of the build.

Reporting one of these is not a moral failing, but it will get a short answer, so it saves us both time to say so up front.

• Missing rate limits on the public API

  Known, deliberate and already documented. The API is keyless and unmetered on purpose, so 'I sent a lot of requests' is a description of the design rather than a finding. A report is still welcome if you have found an amplification primitive — a cheap request that costs us disproportionate work, or one that lets our server be aimed at a third party.

• Volumetric denial of service and load testing

  Do not run it. Degrading a free service for everyone else to demonstrate that it can be degraded is not research, and it is outside the safe harbour below.

• Automated scanner output with no demonstrated impact

  A tool's report pasted in whole, a missing best-practice header with no exploit path, a CVE in a dependency with no reachable call path here, or a version-disclosure banner. Show the impact and it becomes in scope.

• Anything about email authentication

  SPF, DKIM and DMARC findings for this domain. UseQR sends no email at all — there is no mail system to compromise.

• Missing account-security features

  No password policy, no multi-factor authentication, no session timeout, no account lockout. There are no accounts, no sessions and no login. Whole vulnerability classes simply do not exist here.

• Self-XSS and clickjacking without impact

  Attacks requiring the victim to paste code into their own console, or clickjacking on pages that have no authenticated or state-changing action to hijack.

• Third-party services

  Issues in Vercel, GitHub or another provider's own platform. Report those to them; tell us too if it affects UseQR specifically and we will chase it.

• Social engineering and physical attacks

  Against maintainers, contributors or any provider's staff. Always out of scope.

If you make a good-faith effort to comply with this policy while researching, we will consider your research authorised, we will work with you to understand and fix the issue quickly, and we will not pursue or support legal action against you for it. If a third party brings action against you for research that followed this policy, we will make it known that your activity was authorised.

Good faith, concretely, means:

• Only ever accessing data that is yours. If you stumble into anyone else’s data, stop, do not save it, and tell us in the report.
• Not degrading the service for other people: no volumetric testing, no destructive testing, no spam or bulk automated submission.
• Not modifying or deleting anything that is not yours to modify or delete.
• Using the smallest proof of concept that demonstrates the problem, and stopping as soon as it is demonstrated.
• Giving us a reasonable window to fix the issue before you discuss it publicly. See disclosure below.

This safe harbour is ours to give and covers only what we operate. It does not authorise you to test Vercel, GitHub, or any other third party’s systems, and it does not override their policies or the law.

UseQR is maintained by a very small number of people in their spare time. These are honest targets, not a contractual commitment:

• Acknowledgement within five working days.
• Triage and an initial assessment — severity, whether we can reproduce it, and a rough plan — within ten working days.
• A fix as fast as the severity warrants. Because the deployment is continuous and there is no release train, a small fix often ships the same day it is understood.
• A published advisory once users are protected, crediting you by whatever name you choose, or not at all if you would rather.

Please give us 90 days from your report before publishing, or until a fix ships if that is sooner. If we go quiet or a fix stalls, chase us — and if 90 days pass without a resolution, publish. We would rather users hear about an unfixed problem than have our silence weaponised into a permanent embargo.

Because every fix lands as a public commit in an open repository, the change itself is visible before the advisory is written. That is a property of building in the open, and we would rather note it than pretend to a private patch window we do not have.

Stated plainly so nobody wastes an afternoon: we do not pay for vulnerability reports. There is no bounty, no swag budget and no voucher. UseQR is a free public good funded out of one person’s pocket, with no revenue to pay from — and offering a reward we could not honour would be worse than offering nothing.

What we do offer: a fast, respectful response from someone who will actually read your report, public credit in the advisory and in the thanks below, and a fix that protects real people using a tool they did not have to pay for.

Researchers who have reported a valid issue are credited here, and in the published advisory, unless they prefer to stay anonymous. Nobody is listed yet — this page is new. If that is going to be you, the link is above.

A security page that only asks and never tells is half a document, so: static QR generation happens entirely in the browser, so the highest-value data this project touches — WiFi passwords, payment strings, contact details — is never transmitted to us and never stored. There is no database to breach and no credential store to steal. The API is keyless, which means there is no key material to leak. Dependencies are deliberately few, and every one of them is visible in a public lockfile.

None of that makes the project secure by itself. It does mean that when something goes wrong here, it will be in the rendering and fetching paths — which is where we would most like you to look.

Report abuse → · Privacy Policy → · Terms of Service →