Security audit of tarasovvitalii.com: eight findings, eight fixes

tarasovvitalii.com is more than static pages. It runs a chat on VITON ID (Firebase Authentication and Firestore), a small Node API that stores contact messages and sends email, an nginx server in Docker and copies of 15 concept sites under /demos/. A visitor who signs in to write to the founder trusts all of it, so on 28 September 2026 we reviewed the site from the inside, the way we would review a client’s site before launch.

For every part the question was an attacker’s: what can someone outside do with it, and what would it cost the owner? A finding counted only once we had reproduced it, and a fix counted only once the same attack had failed against it.

The review covered every API route and the token verification, the Firestore rules with their 39 emulator tests, the nginx and Docker Compose configuration, the npm dependencies of the site and the API, the chat interface and the code of all 15 demos. Instead of probing the live server, we ran the same containers locally, nginx and the API with production settings, and tried each attack there.

The most serious finding sat in a demo, not in the site itself. The Oriva store concept put the ?cat= address parameter into the page as HTML, so a crafted link ran script on tarasovvitalii.com, the origin where the chat keeps its Firebase session: one click by the owner could have exposed the inbox. The other 14 demos only compare address parameters with known values.

The fixes, finding by finding. The Oriva demo now accepts only known categories and sort orders. /demos/ has its own Content-Security-Policy, and Leaflet, the map library that 52 demo pages load from a CDN, is pinned with integrity hashes. The /demos/<id> redirect is rebuilt from a strict pattern instead of echoing the requested path. Email addresses that could smuggle a hidden BCC or text into the owner’s Reply links are refused, and direction-override characters are stripped from names.

The server got the rest: a global daily cap on stored submissions (500 by default) on top of the per-address limits; the message API running as an unprivileged user on a read-only filesystem with every Linux capability dropped; the nginx version hidden from responses, on the current stable branch; and HSTS, the header that keeps browsers on HTTPS, sent on www as well and extended to subdomains. New API tests cover the refused addresses, the stripped characters and the cap.

Eight findings, eight fixed: one high, one medium and six low. The payload that ran on the old demo code does nothing on the new one, and the request that used to inject a Set-Cookie header now gets a plain 404. All 119 demo pages load under the new policy with zero violations, the API tests pass 48 of 48 with the new rules covered, and npm audit reports no known vulnerabilities in the dependencies of the site or the API.

Checked and found solid: Firebase ID token verification (RS256 only, key id required, audience, issuer and expiry checked), Firestore rules that let no one read another person’s thread or write as the owner, email templates that escape every value, logs without tokens, email or IP addresses, and a chat that never inserts visitor text as HTML. On the live site on 28 September 2026 the response headers show no server version, HSTS with subdomains on both addresses and the demo policy on /demos/, and the header-injection request answers 404.

This is our own site, not client work. The review was done by the studio from the source code; it is not an independent penetration test and not a certificate. The attacks were tried on a local copy of the production containers, not against the live server; only the response headers and the redirect were re-checked on the live address.

The result covers what we checked on 28 September 2026: new code, new dependencies or new demos need the same review again. The demos still share the site’s origin, so the new policy limits what injected code could reach rather than isolating it; moving the demos to a domain of their own would isolate them completely.

How to check a web studio’s portfolio →