Payment Request Permission

This test page demonstrates a security vulnerability where an iframe is granted access to the Payment Request API via the allowpaymentrequest attribute, which increases the attack surface and could potentially lead to financial fraud.

Security Issue: IFrame with allowpaymentrequest attribute that enables the content to access sensitive payment capabilities and potentially initiate payment requests without sufficient context or security.

Test Case

Vulnerable code:

<iframe 
  src="../assets/iframe-content.html" 
  allowpaymentrequest
  width="100%" 
  height="300"
></iframe>

Explanation

The allowpaymentrequest attribute enables embedded content to use the Payment Request API, which provides a standardized way to handle payments on the web. This presents several security concerns:

Iframes could initiate payment requests that appear to come from the parent page
Users may not realize they're authorizing a payment to a third-party rather than the site they're visiting
Malicious content could potentially trick users into authorizing payments under false pretenses
The payment API increases the overall attack surface of the application

Payment capabilities should only be granted to fully trusted and secure content.

How Pink Sock detects this issue:

Pink Sock scans for iframe elements with the allowpaymentrequest attribute and flags them as a security risk, especially when combined with other vulnerabilities like missing sandbox protections or when loading cross-origin content.

How to fix:

Consider these approaches to mitigate the risk:

Only add allowpaymentrequest when absolutely necessary for payment functionality
Only enable payment requests for trusted and verified content sources
Use proper sandboxing alongside payment permissions
Consider handling payments in the parent page instead of delegating to iframes
Implement additional verification steps before payment processing

If payment capability is necessary, combine it with appropriate protections:

<iframe 
  src="../assets/iframe-content.html" 
  sandbox="allow-scripts allow-forms allow-same-origin allow-payment-request"
  width="100%" 
  height="300"
></iframe>

Note that you must also add allow-payment-request to the sandbox attribute if you're using sandboxing with payment requests.

Additional Information

Modern Alternatives

Similar to fullscreen, the allowpaymentrequest attribute is considered legacy. The modern approach is to use the Feature Policy through the allow attribute:

<iframe 
  src="../assets/iframe-content.html" 
  allow="payment"
  width="100%" 
  height="300"
></iframe>

This provides more control and can be combined with other feature policies in a single attribute.

Payment Request API Security Context

The Payment Request API is designed with several security considerations:

It only works in secure contexts (HTTPS)
Browsers often require user interaction before allowing payment requests
The API provides clear disclosure about what is being purchased and from whom

However, these protections don't fully mitigate the risks of enabling payment capabilities in untrusted iframes.

Risk Factors for Payment Requests

The risk level increases significantly when payment capabilities are combined with:

Cross-origin content from untrusted sources
Missing or insufficient sandbox protections
Ability to modify parent page content
Insufficient user education about payment authorization
Misleading context or urgency that rushes users through payment confirmation

Financial capability should always be treated as high-risk and implemented with multiple layers of protection.