Security and Vulnerability Disclosure Policy

1. Reporting a Security Issue

If you think you have found a security vulnerability in removebackgrounds.ai, we want to hear about it. Email support@removebackgrounds.ai and start the subject line with "Security". This is the same address published in our security.txt file.

Please write in English if you can. We do not publish a PGP key or offer end-to-end encrypted email, so do not send working passwords or keys, other people's personal data, or anything that would cause harm if the message were read by someone else. Describe it instead, and we will ask for what we need.

2. What Is in Scope

This policy covers the systems we run for removebackgrounds.ai:

• the website at removebackgrounds.ai and the subdomains we operate under it;
• the background-removal API at api.removebackgrounds.ai;
• the code we send to your browser, including the in-browser image processing;
• the same deployments reached through our hosting provider's default addresses for our projects;
• other domains of ours that redirect to removebackgrounds.ai, and any of their subdomains that still serve our website or API for existing users and clients. These all lead to the same service, so please report an issue once rather than once per domain.

Services we use but do not run, such as our hosting and content delivery provider, our email provider, and our analytics and error-reporting vendors, are not covered: please report problems in those services to the vendor directly. How we set them up and use them is covered — for example, what our pages send to them, our DNS records, or a storage bucket or setting we configured.

Sign-in, where it is offered, is handled by a separate account service that publishes its own security contact. Please report problems in that service there.

3. What We Do Not Treat as a Vulnerability

We read every report. The following are not vulnerabilities for this service unless you can show a concrete way to use them against our users or our systems:

• Automated scanner output about missing or "recommended" DNS, email or HTTP header settings, such as SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, CAA, DNSSEC, security.txt fields or security headers.
• The presence, absence or location of a security.txt file on a particular hostname, and the list of TLS protocol versions or cipher suites a host accepts.
• Software version or banner disclosure, descriptive error messages, and clickjacking on pages that have no sensitive actions.
• Values that are meant to be public and that every visitor's browser receives, such as site keys, analytics and error-reporting identifiers, and other client-side configuration. A secret that was not meant to be public — an access token, a private key or a server-side credential in our JavaScript, source maps or any other public file — is in scope and needs no further demonstration; please do not use it to prove that it works.
• Self-XSS that only works if a victim pastes code into their own browser, and issues that only affect browsers that no longer receive security updates from their maker, or an already-compromised device.
• Problems that can only be shown by sending a large volume of traffic. A single request, or a small number of requests, that crashes the service or exhausts its resources — a crafted image file, for example — is in scope: send it once, stop, and describe it to us.

You do not need to access anyone else's data, or affect the service for anyone else, to show impact. A clear explanation of what an attacker could reach, and how, is enough.

4. How to Test

• Use only your own images, your own browser sessions and, where sign-in is offered, accounts you created yourself.
• Send the smallest number of requests needed to show the problem. Do not run high-volume or automated scanning against the site or the API.
• Do not attempt denial-of-service, load or stress testing, social engineering or phishing of anyone, or any physical testing. None of these is authorized under this policy.
• Do not access, download, change or delete data that is not yours. If you come across someone else's data, stop, do not keep or share a copy, and tell us what you saw.
• Do not use a problem further than you need to confirm it: no moving on to other systems and no persistent access.
• Give us a reasonable time to fix a problem before you publish anything about it. We ask for 90 days from your report, or until we tell you it is fixed, whichever comes first.

Our automated abuse protections apply to all traffic and may slow or block your requests. That is not action against you under this policy.

5. What a Useful Report Contains

• The exact URL, API endpoint or file affected.
• Step-by-step instructions we can follow to reproduce it, including the requests you sent. A short proof of concept helps; a screenshot on its own is not enough to reproduce an issue.
• The impact: what an attacker could do, to whom, and what they would need first.
• When you tested, with your time zone, and which browser or tool you used.

One issue per report is easiest for us to handle. Reports made up only of items listed in section 3 may be closed without an individual reply.

6. No Bug Bounty

There is no bug bounty program. We do not pay for vulnerability reports or security testing, and we offer no other compensation for them, whether or not a report turns out to be valid. Reports are still welcome.

7. Good-Faith Research

If you make a good-faith effort to follow this policy, we will consider your research authorized, we will not treat it as a breach of our Terms of Service or General Terms, and we will not pursue or recommend legal action against you because of it. Where this policy and those terms disagree about security research, this policy applies. If you are unsure whether something is allowed, ask us before you do it.

This applies only to the systems listed in section 2. We cannot authorize testing of other companies' services. It does not cover deliberately accessing, keeping or sharing other people's data; deliberately degrading the service, or continuing once you notice you are degrading it; copying or redistributing our code or models; or asking for payment in exchange for sharing the details of an issue with us, or for not publishing it.

If someone else takes legal action against you over research that followed this policy, we will confirm on request that it was authorized.

8. What to Expect From Us

We aim to acknowledge a report within 14 days, except for reports closed as described in section 5. We are a very small operation, so a reply can sometimes take longer; a slow reply is not a refusal. For reports we can act on, we will try to tell you whether we could reproduce the issue, and to let you know when it is fixed. We cannot commit to a date for a fix.

9. Changes to This Policy

We may update this policy. The "Last updated" date above shows when it last changed.