Security

The architectural claim, stated precisely

For every tool in the Convert, Merge & Split, Clean, Analyse, Security, Generate and Templates categories, your file is read by JavaScript running in your own browser tab, transformed in memory, and written back as a download. No request carries the file contents.

You do not have to take that on trust. Open your browser's developer tools, switch to the Network tab, and process a file. Watch what is sent. This is the only security claim on this page you can verify yourself in thirty seconds, and it is the one that matters most.

The AI tools are the documented exception. They send column names, types and — unless you enable schema-only mode — up to five sample rows. That limit is enforced server-side, not just in the client, so a modified client cannot send more.

What this means for your risk assessment

Because file contents never reach us:

• There is no upload endpoint for an attacker to target.
• There is no retention policy you have to trust us to honour.
• A breach of our infrastructure cannot expose spreadsheets we never held.
• Under GDPR, using the browser-based tools is not a transfer of personal data to us.

That last point is why teams in finance, HR and healthcare can use this where upload-based converters are prohibited outright.

Application security

Passwords are hashed with Argon2id at OWASP-recommended parameters (m=19456, t=2, p=1). Argon2 is memory-hard, which makes GPU-accelerated cracking substantially more expensive than it is against bcrypt.

Sessions use a 15-minute JWT in an HttpOnly, Secure, SameSite=Lax cookie. JavaScript cannot read it, so an XSS bug cannot steal it directly.

Refresh tokens are opaque random strings, stored only as SHA-256 hashes, and rotated on every use. Presenting an already-rotated token revokes the entire token family — the standard detection for a token that has leaked. A password change revokes every session immediately.

CSRF uses an HMAC-signed double-submit token compared in constant time. Bearer-authenticated API requests skip it, correctly: they are not cookie-bound and so are not vulnerable to forgery.

Login always runs a password verification, even for accounts that do not exist, so response timing cannot be used to enumerate registered emails. Forgot-password returns the same message either way, for the same reason.

Brute force is limited to five failed attempts per email and IP combination, then a fifteen-minute lockout, tracked in Redis so the limit holds across every server.

Two-factor authentication uses TOTP with one step of clock-drift tolerance and hashed single-use recovery codes.

Input handling

Every route validates its input with a Zod schema, and the parsed result replaces the raw input. Unknown keys are stripped, which is the actual defence against mass assignment — not a denylist that someone forgets to update.

Uploads to the API are validated by file signature, not extension. A .xlsx whose bytes are not a zip archive is rejected, and an .xlsx containing a vbaProject.bin is rejected as a renamed macro payload. Files are held in memory and never written to disk.

Database access goes through Prisma with parameterised queries throughout. There is no string-concatenated SQL in the codebase.

Transport and headers

TLS 1.2 and 1.3 only, with HSTS preloaded at two years including subdomains. The application sets a strict Content-Security-Policy, frame-ancestors 'none', X-Content-Type-Options: nosniff, Cross-Origin-Opener-Policy and a Permissions-Policy that denies camera, microphone and geolocation outright.

CORS uses an explicit allowlist. An unlisted origin is logged and refused rather than silently permitted.

Operational security

Secrets are validated at boot: the API refuses to start with a missing or too-short signing key rather than failing on the first request that needs it. Logs redact authorisation headers, cookies and every password field.

Authentication and administrative actions are written to an append-only audit log that retains entries with a null actor after account deletion, so the security record survives.

Payment webhooks are verified against the raw request body, and provider event ids are stored so a retried webhook is a no-op rather than a duplicate upgrade.

Responsible disclosure

Email security@exceltoolkitpro.com. We acknowledge within 24 hours and aim to remediate confirmed issues within 30 days.

We will not pursue legal action for good-faith research that avoids privacy violations, service degradation and data destruction. Please do not run automated scanners against production — ask and we will provide a staging environment.

Reporters are credited here unless they prefer otherwise.

What we do not claim

We are not SOC 2 certified yet; that work is in progress and we will not imply otherwise. We do not currently offer a paid bug bounty. Sheet protection is not encryption, and the Password Protector tool says so on its own page rather than leaving you to discover it.