High The application uses unencrypted JWTs, which exposes sensitive claims (e.g., user details, roles, permissions) in plaintext. Since JWTs signed with algorithms like HS256/RS256 provide integrity but not confidentiality, their contents can be decoded by anyone with access to the token.
This could leak sensitive information and increase the risk of privilege discovery, user profiling, or targeted attacks if tokens are intercepted or stored insecurely.
| Vulnerability Name | Vulnerable URL | CVE/CWE | CVSS Score | Overall Risk (Severity) |
Observation / Description | Impact | Recommendation | Reference | Steps to reproduce |
| https://uatamrit.piramalswasthya.org/flw-api/maternalCare/deliveryOutcome/saveAll | Unencrypted JWT | CWE-639 | 8.7 | High | While testing the Android application, an authentication token returned after login was captured. The token is trivially decodable (base64) and the token payload contains the user’s username in clear text. Because the token is visible to the client, logs, and any party that can intercept it, this exposes PII and makes targeted attacks easier. | PII Exposure: Username (identifiable user data) is exposed to any party that can read or decode the token. Reconnaissance Risk: Attackers can enumerate or profile users, enabling phishing, social engineering, or targeted attacks. Token Theft Consequences: If the token is stolen (e.g., via device compromise, insecure storage, or network interception), the attacker gains both access and clear knowledge of the account identity. |
Remove PII from client-visible tokens: Do not include username or other PII in auth tokens issued to the client. Replace with an opaque identifier (sub) that maps to server-side user data. Use opaque or encrypted tokens: Prefer opaque reference tokens validated via a secure introspection endpoint, or use encrypted JWTs (JWE) if token contents must be confidential. Shorten token lifetimes & use secure refresh: Make access tokens short-lived (minutes) and use secure refresh flows with refresh tokens protected by additional checks. Secure storage & transport: Ensure tokens are transmitted only over HTTPS and stored securely on the device (use Android Keystore / EncryptedSharedPreferences; avoid plain SharedPreferences). Server-side authorization & minimal trust: Do not rely on client-visible token claims for authorization — perform all sensitive authorization checks on the server side. |
https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/ | Step 1: During security assessment, we logged into the Android application using valid credentials. Step 2: We intercepted the network traffic (mobile proxy / Burp Suite) and captured the authentication token returned by the server (in the response body / authorization header). Step 3: The token was Base64-encoded (not encrypted). We base64-decoded the token payload. Step 4: The decoded payload revealed the username (and other identifiable details) in plaintext. |
