T09 · Insecure Skill Coding Practices
- Location
references/ap2-pay.md:38- Finding
Card Secret Token Transmitted in a URL Query String
- Content
View full analysis
Vulnerability Details
File Location:
references/ap2-pay.md:38
Vulnerability Type: Secret exposure through a URL query parameter
Risk Level: HighComplete Code Snippet:
http GET https://mag3nt.com/api/ap2/instruments?card_id=<CARD_ID>&card_token=<CARD_TOKEN>Technical Analysis
The documented AP2 instrument-listing request places
card_token, a secret payment credential, directly in the URL query string. Although HTTPS encrypts the request while it is in transit, URLs are commonly recorded by application access logs, reverse proxies, API gateways, observability platforms, browser history, debugging tools, and error-reporting systems.This unnecessarily broadens access to the card token beyond the payment authentication component. It also contradicts least-privilege handling of secrets because operational systems that legitimately require URL visibility may gain access to a reusable payment credential.
Attack Path
- An agent follows the documented AP2 request and inserts its real card ID and card token into the URL.
- The complete request URL passes through Mag3nt infrastructure or another intermediary that records request paths and query strings.
- An attacker compromises a logging account, monitoring integration, support export, proxy log, or developer workstation with access to the recorded URL.
- The attacker extracts the
card_tokenand correspondingcard_id. - The attacker attempts card-authenticated Mag3nt operations, including payment or mandate endpoints that accept these credentials.
Exploitation depends on access to a system that records the URL and on the token remaining valid.
Impact Assessment
Disclosure may expose a reusable card credential capable of authenticating payment-related operations. Depending on server-side authorization, card limits, token scope, and mandate controls, an attacker could inspect card information, create payment m ...[truncated 199 chars]
- Remediation
View remediation
Remediation Suggestions
- Remove
card_tokenfrom the query string. - Use an authenticated HTTPS request with the token in an authorization header, such as a narrowly scoped bearer or card-token header.
- If the API cannot accept authentication headers, change the endpoint to use an HTTPS
POSTrequest with the credential in the request body. - Configure application servers, proxies, API gateways, monitoring systems, and tracing platforms to redact card tokens and sensitive query parameters.
- Apply short token lifetimes, narrow operation scopes, card spending limits, and immediate revocation support.
- Rotate any token that has already been transmitted in URLs and review historical access logs for unintended retention.
- Update the documentation to warn users never to place reusable payment credentials in URLs.
- Remove
