Security Practices

Everything between a visitor's browser and kvoka.com runs over an encrypted channel:

• TLS 1.3 — the current encryption protocol. Older TLS 1.0 / 1.1 / 1.2 are either disabled or marked deprecated.
• HSTS — header Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. The browser remembers for a year that the site is HTTPS-only.
• HSTS preload — kvoka.com is on the HSTS Preload list baked into Chrome / Firefox / Safari. That means even the first visit is HTTPS, no window of exposure.
• HTTP → HTTPS redirect — any attempt to hit http://kvoka.com redirects instantly.
• TLS certificate — Let's Encrypt, auto-renewed every 60 days.

This applies to the main site and to all forms. No data goes over plaintext.

Anything that lands on the server (form submissions, logs, database rows) sits on encrypted disks:

• Hostinger — our hosting provider uses AES-256 disk encryption. See their DPA.
• Backups — daily, also on encrypted disks. 30-day rolling retention.
• Sensitive secrets (API keys, tokens) live in .env files outside the public directory, with file permissions set to 600.
• Database (when a project has one) — MySQL with its own encryption and access restricted to localhost (not exposed to the internet).

Translation: if someone physically stole a disk out of a Hostinger datacenter, the data isn't readable without the keys.

Who has access to what:

• Server SSH — Maks only, key-based (no passwords). SSH password auth is disabled.
• Hosting control panel — Maks only, with 2FA.
• Database — Maks only.
• Telegram lead bot — Maks plus the specific contractor working on a client, only while they're active on that project.
• Email hi@kvoka.com — Maks only.
• GitHub repo — Maks only. When we bring a contractor in, they get time-bound access to the specific branches they need.
• Client credentials (hosting, domain, analytics) — handed to the client at launch and not retained by us. If the client needs support later, they create a separate user account for us and revoke it afterward.

Least-privilege principle — everyone gets exactly the access they need for the task. Nothing more.

Two-factor authentication is on wherever possible:

• Hostinger — TOTP 2FA.
• Domain registrar — TOTP 2FA.
• GitHub — TOTP 2FA plus a hardware key.
• Google Workspace (for hi@kvoka.com) — 2FA plus active monitoring of security alerts.
• Cloudflare — TOTP 2FA.
• Stripe — TOTP 2FA.

We avoid SMS-based 2FA wherever we can — SIM-swap attacks are common enough to make it unsafe. Everywhere uses a TOTP app (Authy, Google Authenticator) or a hardware key (YubiKey).

Passwords are long, unique, stored in a password manager (1Password / Bitwarden).

At the application layer:

• Content Security Policy (CSP) — header limits which scripts can execute. script-src 'self' plus an explicit allowlist for external sources (Google Analytics, Cloudflare).
• Subresource Integrity (SRI) — scripts loaded from a CDN carry a SHA hash. If a CDN file gets tampered with, the browser refuses to run it.
• X-Content-Type-Options: nosniff — browsers don't MIME-sniff.
• X-Frame-Options: DENY — the site can't be iframed (clickjacking defense).
• Referrer-Policy: strict-origin-when-cross-origin — full URLs don't leak to outside sites.
• Form validation — every field is checked on both client and server. Type juggling is blocked with explicit casts.
• Output escaping — all dynamic data goes through htmlspecialchars() or equivalent. No raw echo.
• SQL prepared statements — when there's a database, every query is parameterized. No string concatenation.

Forms on the site are protected against spam and abuse:

• Rate limiting — max 5 submissions per IP per minute. Beyond that, 429 response.
• Honeypot field — a hidden field only bots fill. If it's populated, the submission is dropped.
• Minimum fill time — submissions that arrive in under 3 seconds get flagged as suspicious.
• Origin and Referer checks — cross-domain POSTs from suspicious origins are blocked.
• Request size cap — 10 KB max per form. Anything bigger gets dropped.

We deliberately don't use CAPTCHA — too much friction for real customers. If bot attacks ever get serious, we'll add Cloudflare Turnstile (invisible).

We keep logs:

• Access logs — IP, user agent, URL, status code. Standard nginx format. 30-day retention.
• Error logs — PHP / app errors. If something breaks we have to know what. 90-day retention.
• Form submission logs — who submitted. PII (names, phone numbers, emails) is redacted in logs kept long-term. Full data lives in a separate secured store with 24-month retention.
• Security events — break-in attempts, failed logins, rate-limit triggers. 1-year retention.

What we do NOT log:

• Passwords (not even hashes — those live in the database, never in logs).
• API keys and tokens — auto-redacted in any log line.
• Full message bodies after initial processing.

Backup strategy:

• Daily snapshots — Hostinger takes full disk images nightly.
• 30-day window — we keep the last 30 days of snapshots. You can roll back to any day in the past month.
• Database — separate SQL dump every 12 hours for the last 7 days, plus a daily for the last 30.
• Off-site copy — critical assets (source, configs) are additionally backed up to a separate encrypted bucket.
• Restore testing — we periodically verify backups actually work by restoring a test client site to staging.

Restore goal (RTO): 4 hours for a critical client site. RPO: 24 hours (max possible data loss).

We lean on the security of our subprocessors:

• Hostinger — Tier III datacenters, ISO 27001, annual audits.
• Google Cloud (Analytics, Fonts) — SOC 2 Type II, ISO 27001, ISO 27017, ISO 27018.
• Cloudflare — SOC 2 Type II, ISO 27001, PCI DSS.
• Stripe (when enabled for payments) — PCI DSS Level 1 service provider. Card data never touches our server.

Full list and data categories at Subprocessor List. Each one has signed a DPA with us or has a public DPA we've accepted.

If despite everything an incident happens (data breach, leak, serious intrusion):

• Containment — within an hour of discovery we isolate the compromised system or account.
• Triage — assess scope: which data is touched, how many clients, what the risk is.
• Regulator notification — within 72 hours of discovery (GDPR Art. 33) if EU resident data is affected.
• Affected client notification — no delay, via WhatsApp / Telegram / email, describing what happened, what the risk is, and what you can do (e.g., rotate passwords).
• Postmortem — detailed analysis of root cause, what we did, how to prevent it next time. Public postmortem for politically sensitive cases.

Every step is logged for audit trail.

If you're a security researcher and you find a vulnerability on kvoka.com or on a site we built:

• 📱 Write to WhatsApp or hi@kvoka.com with subject [Security].
• Describe: vulnerability type (XSS, SQLi, IDOR, etc.), reproduction steps, potential impact.
• We confirm receipt within 24 hours.
• Patch — usually 5-14 days depending on severity.
• Coordinated disclosure — public mention of the vulnerability 90 days after patch, with your credit (if you want it).

We do NOT pay bug bounties (we're too small). But we publicly thank researchers in the changelog.

What NOT to do: heavy automated scanning (DOS), social-engineering our clients, physical access to our hardware.

Being straight with you. We don't have:

• SOC 2 Type II audit. Too expensive for a one-person studio. If your client or compliance team requires a SOC 2 audited vendor, you need a bigger shop.
• ISO 27001 certification. Same answer.
• HIPAA compliance / BAA. We don't work with protected health information.
• FedRAMP authorization. Not for us.
• Dedicated security team. Maks handles everything personally.
• 24/7 SOC. If something goes wrong at 3 AM, response may take hours, not minutes.
• Paid bug bounty program. Coordinated disclosure only.

If your business genuinely needs anything on that list, that's fine — we're not the right shop. We'll say so up front.

For any security topic:

• 📱 WhatsApp: wa.me/37120469306
• 💬 Telegram: @maks_kvoka
• ✉️ Email: hi@kvoka.com (use subject [Security] for priority)

Routine reply during business hours is within ~15 min. Serious security incidents get a response within the hour, any time of day.