This document describes the security mechanisms observed in the GdeBenz web client during reverse engineering.

Disclaimer

This documentation is based solely on analysis of the public client-side JavaScript. It does not describe the complete server-side implementation. Server-side validation may include additional protections not visible from the browser.

The client implements multiple independent protection layers designed to reduce spam, abuse, duplicate submissions, and automated traffic.

Observed protection mechanisms include:

• Visitor Token (VT)
• Report Token (RT)
• Comment Token (CVT)
• Browser Fingerprint
• Cloudflare Turnstile
• Geolocation verification
• Vote cooldown
• Rate limiting
• Origin restrictions
• Server-side validation

Browser
    │
    ▼
Generate Fingerprint
    │
    ▼
Request Visitor Token
    │
    ▼
Receive VT
    │
    ▼
User Action
    │
    ▼
(Optional)
Cloudflare Turnstile
    │
    ▼
Compose Request
    │
    ▼
POST /api/comments
    │
    ▼
Server Validation

The Visitor Token is required for submitting votes.

Endpoint

GET /api/vt

Example response

{
    "vt":"2f8819c09b094bb48d4aa407",
    "ttl":1800
}

Runtime variable

window.__VT

Purpose

• Prevent anonymous replay
• Associate requests with a browser session
• Server-side validation

1800 seconds

30 minutes

Automatic refresh

setInterval(vtRefresh,900000)

15 minutes

Used only for report endpoints.

Endpoint

GET /api/rt

Runtime

window.__RT

Header

X-RT: token

Purpose

• Prevent report spam
• Validate report requests

Runtime object

window._cvt

Example

{
    osm:"268902927",
    tok:"9d55291b963b052d3567d04d"
}

Included only when available.

Purpose

• Comment validation
• Anti-spam
• Vote verification

Generated by

getFingerprint()

Example

18ef73bd09d2fd1aabcc1029384756ab

Canvas rendering

Screen resolution

Browser language

Platform

Hardware concurrency

Time zone

SHA-256

Generated via

crypto.subtle.digest()

Fingerprint is cached

_fp

and stored as

gas_cid

The client supports Cloudflare Turnstile.

Runtime variable

window._cfToken

Request field

{
    "cf":"turnstile-token"
}

Purpose

• Bot detection
• Human verification

When available, the client submits

{
    "vlat":55.75,
    "vlon":37.61
}

Only included if

GEO_OK

AND

GEO_PRECISE

AND

!GEO_MANUAL

Client determines whether the user is physically near the station.

Condition

distance_km <= 0.3

Maximum distance

300 meters

Duplicate votes are prevented.

Cooldown

4 hours

Response

409 Conflict

Body

{
    "detail":"revote_cooldown"
}

Votes are cached locally.

Storage

gas_votes

Timestamp storage

gas_votes_t

Purpose

• UI optimization
• Duplicate prevention

Observed response

429 Too Many Requests

Client message

Too many requests.
Try again later.

Observed response

403 Forbidden

Client message

Available only from Russia.

The restriction is enforced server-side.

All observed endpoints use HTTPS.

Example

https://gdebenz.ru/api/comments

Observed Content Security Policy

default-src 'self'

script-src

style-src

img-src

connect-src

font-src

frame-src

object-src

base-uri

form-action

frame-ancestors

Purpose

• Prevent XSS
• Restrict external resources

Observed

Strict-Transport-Security

X-Frame-Options

X-Content-Type-Options

Permissions-Policy

Referrer-Policy

Cross-Origin-Resource-Policy

Likely implemented using

• VT
• RT
• CVT
• Fingerprint

Multiple values are required for successful requests.

Client-side validation is not considered authoritative.

The server validates

• Tokens
• Vote frequency
• Request origin
• Fingerprint
• Geolocation
• Duplicate submissions

Page Load
      │
      ▼
Fingerprint
      │
      ▼
GET /api/vt
      │
      ▼
Receive VT
      │
      ▼
Optional Turnstile
      │
      ▼
Collect GPS
      │
      ▼
POST Vote
      │
      ▼
Server Validation
      │
      ▼
200 OK

The client contains mechanisms intended to reduce:

• Automated voting
• Duplicate votes
• Report spam
• Session replay
• Anonymous abuse
• Basic browser automation

The client alone does not provide complete security.

All critical validation is expected to occur on the server.

Because this documentation is based exclusively on the browser client:

• Server validation logic is partially observed (see below); full backend implementation is unknown.
• Token generation algorithms are unknown.
• Database validation is unknown.
• Internal moderation rules are unknown.
• Rate-limiting implementation is partially observed (documented 429 responses; no thresholds measured).
• Anti-abuse heuristics are partially observed (geolocation/cvt gating; full heuristics unknown).

The following were confirmed by direct anonymous requests, showing where the server — not just the client — enforces checks:

• FastAPI/Pydantic request schemas reject malformed bodies with 422 and a loc list before any auth/token check (e.g. /api/comments, /api/station-suggestions, /api/station-suggestions/check, /api/city/live).
• /api/price and /api/eco require a card token: anonymous → 403 {"detail":"cvt_required"}.
• /api/events create and /api/comments-onsite require a session: anonymous → 401 {"detail":"Unauthorized"}.
• /api/station-suggestions/resolve validates only the URL host (yandex.ru/maps, 2gis.ru); other hosts → 400 {"detail":"bad_url"}.
• Duplicate/banned detection for suggestions is server-side (has_dup, candidates, banned).

These confirm that critical validation is server-enforced and do not rely on the client alone.

The following mechanisms were directly observed in the production client:

• Visitor Token (VT)
• Report Token (RT)
• Comment Token (CVT)
• Browser Fingerprint (SHA-256)
• Cloudflare Turnstile integration
• Geolocation verification
• Vote cooldown (4 hours)
• Local vote cache
• Automatic token refresh
• Secure HTTPS transport
• Security response handling (403, 409, 429)

No attempt was made to bypass or test these protections. This document is intended solely to describe the client-side behavior exposed by the public JavaScript application.