Base64 and cipher bypass testing

Run the Base64 and cipher bypass testing check

What middleBrick covers

  • Test Base64, hex, and nested encoding chains
  • Probe LLM endpoints with encoding bypass attempts
  • Detect unsafe decoding and internal IP exposure
  • Aligns findings with OWASP API Top 10
  • Supports unauthenticated and authenticated scans
  • Provides prioritized remediation guidance

What is payload encoding bypass testing

Payload encoding bypass testing inspects how an API handles obfuscated or transformed malicious input, such as Base64, hex, ROT13, and nested encodings. The goal is to verify that validation and decoding logic does not unintentionally allow dangerous content to reach backend components. Attackers commonly use multiple layers of encoding to bypass weak filters, making this a relevant technique when assessing injection and SSRF surfaces.

Common mistakes when skipping encoding bypass checks

Teams that skip encoding bypass validation often assume that input validation is sufficient if it rejects raw suspicious strings. In practice, attackers can encode payloads to evade pattern-based detection, and frameworks that decode input only once may still process harmful content. This leads to undetected SSRF, unintended command execution, or data exfiltration paths. Relying on ad hoc, manual checks is error-prone and does not scale across many endpoints.

A practical workflow for testing encoding bypass

A robust workflow combines automated scanning with targeted manual checks. Begin with a baseline scan to identify endpoints that accept URL or body parameters, then focus on inputs that interact with parsing, deserialization, or network calls. Test single and nested encodings, validate strict content-type enforcement, and confirm that decoding occurs in a safe context. Document accepted patterns and reject rules that rely on weak blacklists.

Example of a nested encoding sequence to validate decoding behavior:

original = "curl http://internal";
encoded_once = base64(original); // Y3VybCBodHRwOi8vaW50ZXJuYWw=
encoded_twice = base64(encoded_once); // eyJ1cmwiOiAiaHR0cDovL2luZXRlcm5hbCJ9
# Verify that runtime does not recursively decode and execute.

Coverage provided by middleBrick

middleBrick scans for encoding bypass risks across 18 adversarial LLM probes in three tiers (Quick, Standard, Deep). These probes test Base64, ROT13, and mixed encoding chains delivered through URL parameters, headers, and text-only POST bodies. The scanner checks whether transformations are decoded in a way that exposes internal IPs, metadata services, or sensitive routes, and surfaces findings mapped to OWASP API Top 10 categories related to injection and SSRF.

Limitations and complementary controls

middleBrick does not perform active exploitation or attempt to decode payloads on the server. It detects indicators of unsafe handling, such as exposed internal endpoints or error messages triggered by encoded input, and provides remediation guidance. Combine these results with secure decoding practices, strict allowlists, and protocol-level protections. For high-stakes environments, pair automated findings with a human pentest focused on business logic.

Run this check on your API See all use cases

Frequently Asked Questions

Does middleBrick actively decode payloads on the server?
No. The scanner sends encoded strings and observes responses without performing decoding on its own infrastructure.
Which encodings are tested during scans?
Scenarios include Base64, hexadecimal, ROT13, and chained combinations delivered via URL, headers, and POST body.
Can this replace a manual code review of decoding logic?
No. Use these findings as indicators to guide review, but validate decoding behavior and controls directly in your codebase.
Does testing encoding bypass require authentication?
Authentication is optional and domain-verified when provided. Credentials are restricted to a narrow header allowlist and do not enable destructive actions.