Security

The short version

There is no user database to steal and no library of your images to expose, because neither exists. That removes most of the reasons a site like this gets attacked. What remains is the site itself, and we would rather hear about a problem from you than read about it later.

The architecture is the security control

Most breaches of an online tool involve one of three things: an account database, a store of uploaded files, or payment records. This site has none of them.

• No uploads. Image processing happens in your browser using the FileReader and Canvas APIs. Your file never reaches a server, so there is no store of user images to breach, and no backup of one either.
• No accounts. There is nothing to register, so there are no passwords to leak, no password reset flow to abuse and no session to hijack into someone's private files.
• No payments. Everything is free, so no card data ever enters the system.

This is worth stating plainly because it is a structural property, not a promise about how carefully we behave. Data that is never collected cannot be lost.

Transport security

The whole site is served over HTTPS. We send HTTP Strict Transport Security with a long max-age and includeSubDomains, so a browser that has seen the site once will refuse to connect over plain HTTP afterwards, which closes off downgrade attacks on later visits. HTTP requests are redirected to HTTPS.

Browser hardening headers

Responses carry a set of standard protective headers:

Header	What it does
Strict-Transport-Security	Forces HTTPS on subsequent visits
X-Content-Type-Options: nosniff	Stops the browser guessing a file's type and executing it as something else
X-Frame-Options: SAMEORIGIN	Prevents the site being framed by another site for clickjacking
X-XSS-Protection	Legacy filter, retained for older browsers

Third-party code

We keep third-party JavaScript to a minimum, because every extra script is extra risk. The exceptions are the advertising and analytics tags described in the privacy policy, and a small number of specialist libraries used by individual tools for formats a browser cannot handle natively, such as HEIC decoding, PDF rendering and ZIP packaging. Those libraries run in your browser like the rest of the tool, and they process your file locally rather than sending it anywhere.

Reporting a vulnerability

If you believe you have found a security issue, please tell us before you tell anyone else. Send the report through the contact page with "Security" in the subject line.

A useful report includes:

• The URL or page where the issue appears
• What you did, step by step, so we can reproduce it
• What you expected to happen and what actually happened
• Your browser and operating system
• Any proof of concept, screenshot or request or response capture

What we will do

• Acknowledge your report, normally within a few working days
• Investigate and tell you whether we can reproduce it
• Fix confirmed issues as a priority, ahead of feature work
• Tell you when the fix is live, and credit you if you would like to be credited

We do not currently run a paid bug bounty. We will not take legal action against anyone who reports a genuine issue in good faith and follows the guidance on this page.

In scope

• Anything on https://imgcruncher.com that leaks data, allows code execution, or lets one visitor affect another
• Cross-site scripting, injection, authentication or authorisation flaws in the admin area, and insecure direct object references
• A tool behaving in a way that sends image data off the device, which would contradict the entire premise of the site and which we would treat as critical

Out of scope

• Reports produced by an automated scanner with no demonstrated impact
• Missing headers or best practices with no exploitable consequence
• Denial of service, volumetric testing, or anything that degrades the site for other people
• Social engineering of us or our hosting provider, and physical attacks
• Issues in third-party advertising or analytics code, which should go to the vendor concerned

What we ask of you

Please test only against your own browser session, do not access or modify anyone else's data, do not run destructive or high-volume tests, and give us a reasonable opportunity to fix an issue before publishing it. If a proof of concept requires data, use your own.

What you can do at your end

Keep your browser updated, since the tools depend on the browser's own image handling. If you are working with sensitive images, note that the risk is on your device rather than on our servers: a screen someone can see, a shared computer, or a file left in a downloads folder. Our image privacy page covers verifying for yourself that nothing leaves your machine, and the metadata viewer shows what is hidden inside a photo before you share it.

Contact

Security correspondence goes through the contact page. Related: privacy policy, image privacy.