Dynamic Endpoint Obfuscation via Symmetric Encryption: OneBlinc Case Study

Context

In 2025, OneBlinc — a fast-growing mobile-first fintech — faced a critical security problem: malicious actors were mapping its API Gateway endpoints and, combining that map with credentials leaked in dark web groups, running fuzzing attacks that exploited unpatched vulnerabilities.

Imara Trust was engaged to design a rapid mitigation solution. The response came in two complementary components that form a single architecture: dynamic endpoint obfuscation via symmetric encryption, which renders endpoints completely opaque to any external actor, and a semantic traffic identification mechanism via X-Crypto-Alias, which preserves operational observability even with obfuscated URLs. The result was complete elimination of attacks within 30 days.

The Problem

OneBlinc's attack surface was wide for two independent reasons.

First, API endpoints were static and predictable. Once an attacker mapped /v1/loan/apply, /v1/payment/process, or /v1/user/validate, they could build targeted payloads and probe input variations indefinitely. Tools like Burp Suite and nuclei do exactly this in an automated fashion.

Second, legitimate user credentials were available on the dark web. This meant attackers didn't need to bypass authentication: they could use valid tokens to access documented endpoints and probe payload variations from an authenticated session.

The combination of predictable endpoints and leaked credentials created an attack vector that was difficult to detect via conventional WAF, because malicious traffic appeared legitimate.

Solution Architecture

The solution operates across three integrated layers, where obfuscation and semantic identification are designed together from the start.

Layer 1 — Build nonce and mobile app protection

At build time, a unique nonce (UUID v4) is generated and stored in a protected form within the app bundle by AppDome or DexProtector (Licel). These tools apply bytecode obfuscation, emulator detection, anti-tamper, and root/jailbreak detection. The nonce is not visible in network traffic and cannot be extracted by reverse engineering without breaking the runtime protections.

The server also validates device integrity signals at key issuance time: SafetyNet/Play Integrity attestation (Android) or DeviceCheck/AppAttest (iOS). Compromised devices do not receive a key.

Layer 2 — Symmetric key distribution

When the app starts, it calls the only permanent and public endpoint in the system: /resolve/key. This endpoint validates the authentication JWT, verifies the build nonce, and issues a symmetric key with a short TTL (typically 15 minutes). The response also includes the valid alias map for the session, binding semantic identity to the cryptographic key.

def resolve_key(request):
    verify_jwt(request.headers["Authorization"])
    verify_build_nonce(request.headers["X-Build-Nonce"])
    key = generate_symmetric_key(ttl=900)
    aliases = get_session_aliases(request.user)
    return {"key": key, "aliases": aliases, "expires_at": utcnow() + 900}

Layer 3 — Endpoint obfuscation and semantic identification

With the key available, the app computes the real endpoint at runtime using one of two possible models depending on the desired security level. In parallel, every request carries the X-Crypto-Alias header with the semantic identifier of the operation.

In the HMAC model, the endpoint is derived as a hash of the real path concatenated with a fixed-window timestamp. It's deterministic and efficient, but the computed endpoint is the same for all clients within the same time window.

In the AES-GCM model, the path is encrypted with the distributed key and a random IV. The result is sent as the request path. This model generates a different endpoint on every call, even for the same real path.

// Flutter client — request with obfuscated endpoint and semantic alias
final iv = generateRandomIV();
final encryptedPath = aesGcmEncrypt(realPath, sessionKey, iv);
final obfuscatedPath = base64url(iv + encryptedPath);

await http.post(
  Uri.parse('$baseUrl/$obfuscatedPath'),
  headers: {
    'Authorization': 'Bearer $token',
    'X-Crypto-Alias': 'loan.apply',
  },
  body: payload,
);

On the server side, the obfuscation middleware decrypts the path and the alias middleware validates that the alias matches the real operation, rejecting requests where they diverge.

class ObfuscationMiddleware:
    def __call__(self, request):
        raw = base64url_decode(request.path.lstrip('/'))
        iv, ciphertext = raw[:12], raw[12:]
        request.path = aes_gcm_decrypt(ciphertext, session_key, iv)
        return self.get_response(request)

ALIAS_MAP = {
    'loan.apply': '/v1/loan/apply',
    'payment.process': '/v1/payment/process',
    'user.validate': '/v1/user/validate',
}

class AliasRoutingMiddleware:
    def __call__(self, request):
        alias = request.headers.get('X-Crypto-Alias')
        if ALIAS_MAP.get(alias) != request.path:
            return HttpResponse(status=400)
        return self.get_response(request)

Why X-Crypto-Alias Is Part of the Security Solution

Obfuscation solves the endpoint exposure problem but creates a second one: CloudWatch logs, WAF rules, and API Gateway dashboards start recording only hashes or ciphertext as the request path. It becomes impossible to distinguish a POST /v1/loan/apply from a POST /v1/payment/process in the logs, which breaks anomaly alerts, granular rate limiting, and incident analysis.

A naive solution would be to decrypt paths in an intermediate log pipeline — but that increases operational complexity, creates a failure point, and exposes real endpoints in another context.

X-Crypto-Alias solves this elegantly: the client semantically declares what it's doing without revealing the real endpoint. The server validates that the declaration is true (alias ↔ decrypted path). Logs and observability systems use the alias directly.

Alias Types

The system supports three alias models, chosen based on the operational needs of each endpoint.

In the 1-to-1 model, a fixed alias always maps to the same real endpoint. Suitable for high-value operations with predictable volume, such as /v1/loan/apply.

In the 1-to-N model, an alias corresponds to a group of related endpoints. Useful when exact endpoint granularity isn't needed in logs — for example, grouping all profile read operations under user.read.

In the dynamic model, the alias is generated by the server at key distribution time and rotated along with the key. There's no fixed alias an attacker can try to reproduce.

Observability Across the Full Stack

With X-Crypto-Alias in the logs, the entire observability stack works normally without decrypting anything.

API Gateway log template:

{
  "requestId": "$context.requestId",
  "alias": "$context.requestOverride.header.x-crypto-alias",
  "status": "$context.status",
  "ip": "$context.identity.sourceIp"
}

CloudWatch Logs Insights query for latency by operation:

fields @timestamp, httpMethod, xCryptoAlias, status, @duration
| filter xCryptoAlias = "loan.apply"
| stats avg(@duration) by bin(5m)

WAF rate-limiting rule, scoped by alias:

{
  "Name": "RateLimit-LoanApply",
  "Statement": {
    "RateBasedStatement": {
      "Limit": 100,
      "AggregateKeyType": "HEADER",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "FieldToMatch": {"SingleHeader": {"Name": "x-crypto-alias"}},
          "SearchString": "loan.apply"
        }
      }
    }
  }
}

Results

After 30 days of implementation:

• Fuzzing attacks: 100% eliminated. Without the real endpoint, automated tools cannot construct valid payloads.
• Attacks using leaked credentials: rendered ineffective. Valid credentials are not sufficient without the runtime-computed endpoint.
• Latency overhead: under 2ms per request for HMAC; under 4ms for AES-GCM.
• Observability: fully preserved. Logs, dashboards, and WAF rules work with aliases without requiring decryption in monitoring systems.

The architecture demonstrated that security and observability are not conflicting goals: when designed together from the start, the cryptographic component and the semantic identifier reinforce each other.