Testnizer
EN TR
Download
Security model

Three load-bearing rules,
enforced by code.

We don't ask you to trust us. We make it architecturally impossible for the app to send your data anywhere you didn't tell it to.

1

CSP connect-src self

The renderer's Content-Security-Policy header is set to connect-src 'self' — the React UI is physically incapable of opening a connection to anything except its own origin. Every API call goes through an audited Node main-process IPC handler that you, the user, control.

2

Process isolation by default

contextIsolation is on. nodeIntegration is off. The preload script exposes only an audited window.api surface — no raw fetch, axios, or require from the UI thread.

3

Secrets pass through OS keychain

Passphrases, basic-auth passwords, bearer tokens, OAuth refresh tokens, and certificate keys all go through Electron safeStorage — Keychain on macOS, DPAPI on Windows, libsecret on Linux. Only encrypted blobs touch SQLite. Raw values never write to disk.

4

Zero telemetry by design

There is no analytics endpoint. No 'phone home' on launch. No background sync. No anonymous usage stats. Auto-update only runs when you ask it to, and you can turn it off in Settings.

What this means in practice

Six things Testnizer doesn't do.

No telemetry

We don't have an analytics endpoint to disable. There is no opt-in either.

No login

No account creation. No SSO. No vendor server even knows the app exists.

No cloud sync

Your collections live in a local SQLite. Backups are your responsibility. That's the trade-off.

No background egress

The renderer's CSP blocks it. The main process only opens connections you trigger.

No third-party JWT decode

Decode runs locally with Node's crypto module. The token never leaves the process.

No third-party XML signing

WS-Security uses xml-crypto + Node crypto, all main-process. Private keys load from disk in-memory only.

Cryptography

All keys stay on disk. All operations run in process.

XML signing and encryption use Node's native crypto plus xml-crypto and xml-encryption. Both run in the main process. Private keys are loaded from disk into memory on demand, used for the single operation, and zeroed when the request completes.

JWT verification runs against an HS / RS / ES algorithm catalogue inside the same main process — there is no helper service, no online verification step, no shared secret pool.

Stored secrets — basic-auth passwords, bearer tokens, OAuth refresh tokens, certificate passphrases — pass through Electron's safeStorage API. On macOS that delegates to Keychain. On Windows, DPAPI. On Linux, libsecret. The raw plaintext never writes to your project's SQLite database; only the OS-encrypted blob does.

Master password gating is opt-in. When enabled, the app derives a key with PBKDF2-SHA256 (120,000 iterations) and uses it to envelope-encrypt the entire SQLite database before save.

Audit-ready

Reviewable, reproducible, owned by you.

Open source

Full source on GitHub. Your security team can read every line of the IPC handlers, every protocol engine, every database query. Build from source if your compliance posture requires it.

Reproducible builds

CI publishes per-platform installers from tagged commits. Hashes are visible in the GitHub Actions run output and in the GitHub Release. You can verify what you downloaded matches what was built.

No phone-home in the binary

The shipped binary contains no analytics SDK and no remote configuration endpoint. You can confirm with strings, tcpdump, or your favourite EDR.

Air-gapped install

Download the installer once, transfer it onto an isolated network. Auto-update is disablable. Documentation ships in-app — you don't need internet to read it.

Found a vulnerability?

Email info@testnizer.com. Please don't open a public issue for security concerns. We'll triage within five working days.