Security Policy

Itnetic Technologies

Last updated: 31 July 2026

This document describes how Itnetic secures the Service and how to report a vulnerability. It forms part of the Terms of Service; the contractual version of these measures is Annex II of the DPA (Article 32 GDPR).

We are a single-operator company. That shapes the security model: there is no large access surface to control, but also no separation of duties. We state both plainly rather than implying a team we do not have.

1. Reporting a vulnerability

chlibekbusiness@gmail.com — subject [SECURITY]. Machine-readable contact: https://itnetic.com/.well-known/security.txt.

Please include steps to reproduce, the affected host or endpoint, and the impact you believe it has. Czech or English.

Our commitments

Acknowledgement within 72 hours.
An assessment and a remediation plan within 10 business days.
We will tell you when the fix ships, and credit you publicly if you want.

Safe harbour. If you research in good faith and follow the rules below, we will not pursue legal action or report you, and we will treat your research as authorised under Section 2(11) of the Acceptable Use Policy:

Test only against your own account and domains, or against itnetic.com itself.
No denial-of-service, no volumetric load testing, no spam, no social engineering, no physical attacks.
Do not access, modify, or retain another customer's data or their visitors' data. If you encounter such data, stop, and tell us what you saw.
Give us a reasonable period to fix the issue before disclosing it.

We do not run a paid bug bounty.

2. Product security

Encryption in transit

TLS between visitors and the edge; certificates issued and renewed automatically over ACME.
TLS between the edge and the origin wherever the origin supports it.
HTTP/2 to origins where offered; WebSocket upgrades handled explicitly.
Requests to private object-storage origins are individually signed (AWS SigV4) and never dialled anonymously — a private origin without credentials fails closed.

Encryption at rest

Provider-level disk encryption at our hosting and database providers.
Account passwords are stored as bcrypt hashes (cost 12) and never in plaintext or in a reversible form.
Stored third-party credentials (object-storage keys) are additionally encrypted with AES-GCM under a key held outside the database, so a database dump alone does not yield them.

Authentication

Email verification is a hard gate: an unverified account cannot authenticate at all.
Passkeys (WebAuthn) are supported for dashboard sign-in.
A bot check (Cloudflare Turnstile) protects sign-in and sign-up.
Sign-in and sign-up are rate-limited per IP.
Sessions are tracked server-side and can be revoked; changing a password revokes every other session immediately.
API tokens are per-account JWTs signed with a separate secret from the session machinery, so a leaked API token cannot be replayed against sign-in. Every API request re-resolves the token record, which is what makes revocation take effect immediately.
Edge nodes authenticate to the control plane with 15-minute tokens, not long-lived secrets, and a disabled node's tokens stop working within 30 seconds.

Network and platform

The edge is segmented from the control plane; the dashboard has no direct HTTP path into the control plane.
Abusive sources are dropped in the kernel firewall (nftables), before they reach the application.
Connection-admission limits protect against TLS handshake floods, which are paid before any application logic runs.
Origins are validated against SSRF: only range-checked public addresses are ever dialled, never a hostname supplied at request time.
Edge nodes run as containers built from a minimal image; the dashboard runs on a distroless base image with no shell.
Deployments are blue/green with an overlapping drain window, so a release neither drops live connections nor leaves the port unbound.
Redundancy across multiple points of presence; volumetric attacks are absorbed upstream by OVHcloud.

Data handling

Request and response bodies are never stored.
Query strings are stripped from logged URLs.
Retention limits are enforced by database TTL indexes, not by a clean-up job that can be forgotten — see the Data Retention Policy.
Analytics are self-hosted and consent-gated; we do not use session recording, Google Analytics, or advertising trackers.

3. Operational security

Access. The operator is the only person with production access. There is no shared production credential and no standing third-party access.
MFA is enabled on every provider and infrastructure account.
Confidentiality obligations bind the operator and every sub-processor.
Monitoring. Security logging of requests and mitigation decisions, automated anomaly detection against per-host traffic baselines, and alerting on attack events.
Dependencies. Security updates to the runtime and dependency tree are applied on a rolling basis; the container images are rebuilt on each release.
Vendor review before any sub-processor is added — see the Sub-processor list.

4. What we do not claim

Honesty is more useful to you than a checklist:

We are not ISO/IEC 27001 certified and not SOC 2 audited. If you need either, tell us before contracting.
There is no separation of duties — the operator can both change code and deploy it.
There is no 24/7 on-call rota. Attack mitigation is automated and runs unattended; human response follows the targets in the Incident Response Policy.
Penetration testing is not performed on a fixed external schedule.

5. Incidents

Security incidents, including personal-data breaches, are handled under the Incident Response Policy: notification to the supervisory authority within 72 hours where required, and to affected customers without undue delay.