FileKiwi

Security policy

Last updated: October 5, 2026

Keeping your files safe is the core of FileKiwi. This page explains how we protect the service and how to report a security problem to us.

1. How we protect your files

  • Local first. Most tools process files in your browser, so the file never leaves your device. This is the strongest protection there is: we cannot lose, leak or misuse what we never receive.
  • Encryption in transit. The whole site is served only over HTTPS, with HTTP Strict Transport Security (HSTS).
  • Short lived server files. Files sent to server tools get a random name, are stored in a private folder outside the public web root, and are deleted immediately after processing. A cleanup job removes anything left behind within one hour.
  • No public links. Results are returned only to the browser that sent the file. We never create shareable download links.
  • Input validation. Server tools check file types and sizes, accept requests only from our own website, and use rate limits against abuse.
  • No third party code. We load no advertising, analytics or external scripts that could read the page, and all files including fonts and AI models are served from our own server.
  • Hardened headers. We send security headers such as X-Content-Type-Options, X-Frame-Options, Referrer-Policy and a restrictive Permissions-Policy that blocks camera, microphone, location and payment access.

2. Reporting a vulnerability

If you believe you have found a security vulnerability in FileKiwi, please report it to contact@filekiwi.com with the subject "Security". Our machine readable contact details are published in security.txt. Please include:

  • a description of the issue and its possible impact;
  • the affected URL, tool or endpoint;
  • steps to reproduce, or a proof of concept;
  • how we can contact you for questions.

We will confirm receipt within 5 working days, keep you informed about progress, and let you know when the issue is fixed.

3. Rules for good faith research

When researching, please:

  • test only against your own files and never access, modify or delete data that does not belong to you;
  • do not run denial of service tests, mass scanning, brute force attacks or anything that degrades the service for others;
  • do not use social engineering, phishing or physical attacks, and do not target our hosting provider's infrastructure;
  • give us reasonable time to fix the issue before you disclose it publicly, normally 90 days;
  • stop and report to us as soon as you have confirmed a vulnerability.

If you follow these rules, we will consider your research to be authorised, will not take legal action against you for it, and will work with you to understand and resolve the issue. If a third party takes legal action against you for activities that followed this policy, we will make it known that your actions were authorised by us.

We do not currently run a paid bug bounty programme, but we are happy to thank researchers publicly with their permission.

4. Out of scope

  • Reports from automated scanners without a demonstrated impact.
  • Missing best practice headers or settings without a concrete security consequence.
  • Rate limiting findings that only affect your own requests.
  • Issues that require a compromised device or browser, or outdated browsers.
  • Self cross site scripting that cannot be used against other users.