GH GambleHub

API security and request filtering

1) Why do you need it

API - external and internal platform border. Any error in authentication, authorization, validation or normalization of requests turns into exploitation of vulnerabilities (BOLA/IDOR, injection, SSRF, massive enumeration, resource exhaustion). Purpose: Create defense-in-depth from perimeter to business rules, with measurable SLOs and risk control.

2) API Inventory and Classification

API directory: register of all services/endpoints, owners, versions, client types (web, mobile, partners), mode (public/partner/internal), PII/financial data.
Criticality: High (financial transactions/authorization), Medium (profile reading), Low (public directories).
Attack surface: REST, GraphQL, gRPC, WebSocket, webhooks.
Status: prod/staging/experimental, deprecate policy, token/key lifetime.
Shadow/abandoned API: detection through ingrest logs, eBPF/Service Mesh telemetry, comparison with a directory.

3) Threat model (brief)

Identification: token hijacking, session commit, MitM, replay.
Authorization: BOLA/IDOR, horizontal/vertical escalation.
Input: injections (SQL/NoSQL/LDAP), template/serialization, path traversal, headers.
Traffic: DDoS/L7 floods, slow requests, phantom retrays.
Integrations: insecure webhooks, SSRF via URL parameters, file/scan downloads.
Logic: abuse of bonuses, racing, inconsistency of idempotence.

4) Basic safety standard (minimum)

1. TLS 1. 2 + everywhere; HSTS; weak ciphers are disabled.
2. Authentication: OAuth2/OIDC for clients, mTLS/or HMAC - service-to-service.
3. Authorization: Centralized PDP (RBAC/ABAC), Object Level Inspection (BOLA).
4. Validation: strict scheme (OpenAPI/JSON Schema/Protobuf), failure with extra fields.
5. Limits: rate/quotas + burst, per-client/per-IP/per-token.
6. Idempotence on write operations, protection against repetitions/races.
7. WAF/gateway filtering: path/header normalization, deny lists, payload-anti-patterns block.
8. Secrets: KMS/Vault, key/certificate rotation, leak control.
9. Observability: tracing, security audit logs (who/what/when/result), alerts.
10. Procedures: playbook incidents, test cases and regular pentests/DAST.

5) Authentication and token management

OAuth2/OIDC: short-lived access tokens, refresh strictly according to OIDC; audience/issuer/exp are checked on the gateway.
JWT: RS256/ES256; minimum set of clams; 'nbf/exp/aud' are required; prohibition of PII storage. Key rotation via JWKS.
DPoP/PoP: Bind token to client key to reduce risk of replay/hijacking.
mTLS for internal systems and trusted partners (CN/SAN qualification, CRL/OCSP).
HMAC (signatures): deterministic canonicalization (method + path + timestamp + nonce + body-hash); valid time window (± 30s).
Browser sessions: SameSite = strict/lax, HttpOnly, Secure; CSRF protection (double submit/state tokens).
Client storage: on the mobile - secure storage (Keychain/Keystore), debug protection, pinning certificates.

6) Authorization (BOLA-first)

Object-level: each operation checks the right to a specific resource (resource owner/scope/attributes).

RBAC/ABAC: roles + attributes (country, segment, risk limits, KYC level)

Policies: deny-by-default; explicit allow; Policy versioning tests for negative cases.
Decision cache: adaptive TTL + disability in changing roles/segments.

7) Filtering and normalizing requests (on gateway/WAF)

Normalization: compression of repeated slashes, prohibition '../', decoding once, trimming spaces/zero bytes.
Headers: allow-list ('Host', 'Content-Type', 'Accept', 'Authorization', 'Date', 'Idempotency-Key', necessary trace headers).
Methods: 'GET/HEAD' without a body; 'POST/PUT/PATCH' - with type 'application/json' or strictly allowed.
Dimensions: max-body, max-headers, max-path; early-reject 413/431.
Files: MIME validator, antivirus/sandbox, active content prohibition, image recycling/sanitization.
URL redirects/fetchi: SSRF block (deny private ranges/metadata IP, schema only 'https', allow-list domains).
SQL/NoSQL patterns: injection signatures via WAF rule-sets + server parameterization of queries.

Example Header Policy (Pseudo Format)


deny_headers: ["X-Forwarded-Proto","X-Original-URL","Proxy-Connection","Destination"]
require_headers: ["Authorization" (для protected), "Content-Type" (для write)]
strip_duplicates: true max_header_count: 32 max_header_size: 16KB

8) Limits, quotas and antibot protection

Rate limiting: token-bucket/ leaky-bucket; levels - per IP, per API key, per user, per org.
Quotas: daily/monthly, separate for write/extensive methods.
Adaptivity: dynamic tightening under anomalies (sudden burst/credential stuffing).
Slow-loris/slow-POST: read/keep-alive timeouts, concurrent connection restriction.
Antibot: device-fingerprint, behavioral signs, proof-of-work/captcha for increased risk, list of torus/proxy networks.
IP control: geo/ASN filters, deny lists of "dirty" subnets, allow lists for partners/admin panels.

9) Validation of input data and circuits

Fail-closed: Everything that fails the scheme is 400. Extra fields - reject.
Types/ranges: numbers, dates (UTC/ISO-8601), enum values, line lengths, regexps.
JSON-quality: max-nesting, prohibition of large arrays/keys, canonical order (optional).
Business validation: idempotency according to 'Idempotency-Key'; anti-fraud rules (operation frequency limits, amount caps).
GraphQL: depth/complexity limits, allow-listed queries, authorization per field.
gRPC: strict Protobuf schemes, mandatory fields, message size limits.

10) Webhooks and external calls

Signatures: HMAC with timestamp/nonce; verification prior to processing; window +/- 5 min.

Delivery: Retrai with exponential pause and jitter; max-attempts; Event ID deduplication

Vendor IP allow-list separate subdomain/path; minimal hosting stack.
Answers: 2xx only after a successful internal recording; otherwise 4xx/5xx with clear code.
Outgoing SSRF control: when callback URL - allow-list, deny private addresses.

11) Encryption and secret management

In the channel: TLS 1. 2+/1. 3, pinning, strict cipher policy.
Alone: DB/object storage encryption, separate keys for PII/financial data.
KMS/Vault: centralized storage of secrets, short TTL, automatic rotation.
Keys and certificates: separate for environments; audit of issues; prohibition of output to logs.
Token-introspection: offline revocation lists, short'exp '.

12) Observability, audit and response

Security logs: authentication attempts/successes, authorization failures, rate-limit events, role/limit changes.
Tracing: correlation-ID end-to-end; external call tracing.
Metrics: RPS, P95/P99 latency, error-rate by code, share of 401/403/429, hit-rate limits, anomalies.
Alerts: 401/403/429 spikes, 5xx growth, frequent idempotency conflicts, sharp deviations of the QL-complexity graph.
Playbooks: blocking keys/tokens, quickly rolling back rules, warming up the deny list, notifying service owners.
Forensics: preservation of controversial payload (with secure PII editing), replay on an isolated stand.

13) Errors and answers to the client

Uniform error format (code, message, trace-id, category).

No leaks: do not disclose SQL, table names, internal idies; 403 instead of "why not."

Codes: 400 (validation), 401 (no authentication), 403 (no rights), 404 (mask existence), 405/406, 413/429, 500/503.
Retry-Hints: для 429 — `Retry-After`; for idempotency - advice on repetition with the same key.

14) Architectural patterns

Zero-Trust: mTLS, explicit authorization between all services, minimal privileges.
API gateway + WAF + service mesh: separation of duties - perimeter, L7 policies, internal authentication.
Canary/Blue-Green: Roll out new filtration rules in stages with supervision.
Fail-closed: for critical write, it is better to refuse safely than to allow incorrect operation.
Backpressure: queues/buffers, circuit breaker, timeouts/budgets.

15) Examples of practical rules (pseudo-config)

15. 1 Limiting paths and methods


/api/v1/payments:
allow_methods: [POST, GET]
auth: oauth2_required body:
content_type: application/json max_size: 256KB

15. 2 Idempotency


require_header: Idempotency-Key (UUIDv4)
store: redis:ttl=24h on_duplicate: return_previous_result

15. 3 Request Signature (HMAC)


signature:
scheme: "HMAC-SHA256"
required_headers: ["X-Signature","X-Timestamp","X-Nonce"]
allowed_drift: 300s string_to_sign: METHOD + "\n" + PATH + "\n" + SHA256(body) + "\n" + X-Timestamp + "\n" + X-Nonce

15. 4 SSRF protection


outbound_http:
allowlist_domains: ["kyc. partner. com","psp. example. net"]
block_private_ip: true require_https: true

15. 5 GraphQL limit


graphql:
max_depth: 8 max_complexity: 500 allowlisted_operations_only: true

16) Specifics of iGaming/Finance

Segment limits: depending on the CCM/country/risk profile.
Time windows: deposit/withdrawal frequency rules, "cooling down" between transactions.
Bonus anti-abuse: consistent locks on account/device/IP/payment tool.
Audit of regulatory requirements: storage of logs of actions and decisions (KYC/AML), retention periods, unchanging logs.

17) Prod Ready Checklist

  • Full API directory and data flow map (PII/financials tagged).
  • OpenAPI/Protobuf schemas, validation tests and contracts in CI.
  • mTLS/HMAC/OAuth2 configured; short TTL tokens; key rotation.
  • BOLA tests and negative authorization cases; centralized PDP.
  • Limits/quotas/anti-bot, protection against slow-loris; IP filters.
  • WAF/gateway normalization rules, anti-injection signatures.
  • Idempotency of write operations; protection against replay.
  • Webhook signatures and allow-list; isolated endpoints.
  • Secrets in KMS/Vault; encrypted storages; alerts to anomalies.
  • Dashboards, alerts, audit logs; worked playbooks incidents.
  • Regular pentest/DAST/SAST, vulnerability tracks and patch download.

18) Antipatterns (which is not possible)

Trust 'X-Forwarded-' without rigid TLS on its perimeter.
Accept arbitrary'Content-Type 'and "soft" JSON schemes.
Long-lived JWTs without recall/rotation.
Mix roles and business rules in code without centralized policies.
Logs with secrets/PII; detailed 500-message outward.
"Temporary" open endpoints without limits and authorization.

19) Versioning and Deprekate

Versions in the path/header; support policy (e.g. N-2).
Announcements: deadlines for deprecate, monitoring the use of old versions, controlled shutdown.
Compatibility: customer/partner contracts and test matrices.

20) Safety testing

Contract tests of schemes/policies, fuzzing inputs, negative auth.
Performance profiles with limits/quotas, protection test (chaos traffic).
Red-team/bug-bounty: BOLA scripts, SSRF, signatures/replays, GraphQL-complexity.

TL; DR

1. API directory + strict schemes.
2. OAuth2/OIDC for clients, mTLS/HMAC inside.
3. BOLA perimeter per resource (ABAC/RBAC).
4. Filtering: normalization of paths/headers, limits, WAF rules.
5. Idempotence, signatures, replay/SSRF protection.
6. KMS/Vault and secret rotation.
7. Observability, alerts, playbooks.

Contact

Get in Touch

Reach out with any questions or support needs.We are always ready to help!

Telegram
@Gamble_GC
Start Integration

Email is required. Telegram or WhatsApp — optional.

Your Name optional
Email optional
Subject optional
Message optional
Telegram optional
@
If you include Telegram — we will reply there as well, in addition to Email.
WhatsApp optional
Format: +country code and number (e.g., +380XXXXXXXXX).

By clicking this button, you agree to data processing.