I have had a customer come to me with a failed PCI compliance check with the failure apparently caused by an extension I develop. The scenario is that web page content is served by the extension but a particular string is replaced in the pages HTML server side with the contents of a cookie. This is flagging a security issue on the compliance check even though the cookie contents is being passed through the PHP function htmlspecialchars(). With the cookie removed completely the check passes. The strange thing is the same check passes on another website using exactly the same extension but with the cookie present.

What have I missed?

EDIT: To give a bit more detail as per the request in the comment, the value is output in HTML, and the exact failure as shown in the report is as follows:

Affected URL:
http://www.somestore.com/somepage.html Affected Variable: cookie_name Injected
a8dbc5753b48066661972c446c248ef44c94800554c44cd// Variation ID:
Cross-Site Scripting in event tag of HTML element
  • Some more details are needed. Where is the value output, in HTML or JavaScript? What's the exact reason for failure? Mar 2, 2016 at 10:12
  • This is interesting, out of curiosity is the sites that passes SSL?
    – TheHidden
    Mar 2, 2016 at 12:19
  • The SSl certificate is up to date and there are no insecure assets on the page when accessed securely. Mar 2, 2016 at 12:26
  • I'm guessing this is not an easy one to shed any light on? Mar 2, 2016 at 17:06
  • Do you apply the html encoding before setting the cookie or do you apply it when you include the cookie in the html? The former is an XSS vulnerability. Nov 5, 2016 at 9:47

1 Answer 1


You customer is probably trying to qualify for PCI's SAQ A certification, but your extension would require them to use SAQ A-EP. See the guideline document here.

Specifically the 5th requirement for A-EP:

Each element of the payment page(s) delivered to the consumer’s browser originates from either the merchant’s website or a PCI DSS compliant service provider(s)

This is in contrast to what's required for SAQ A, which requires that everything be outsourced.

This page goes into some more detail about what this difference means (emphasis mine):


  • Merchant website is entirely hosted and managed by a PCI-compliant, third-party payment processor, OR
  • Merchant website provides an iframe or URL that redirects a consumer to a PCI-compliant, third-party payment processor, where no elements of the page originate from the merchant website.


  • Merchant website creates a payment form and “direct posts” payment data to PCI-compliant, third-party payment processor, OR
  • Merchant website provides an iframe or URL that redirects a consumer to a PCI-compliant, third-party payment processor, BUT some elements of the payment page originate from the merchant website. (Elements would be JavaScript, CSS or any functionality that supports how the payment page is created.)

Your other customer is probably already under A-EP, so your extension doesn't pose a problem for them.

  • Thanks for the reply. Hmmm, still not clear on why the logic the extension is running is causing an issue though. The error is on a Magento store, and the payment options for Magento either take you off the site completely, i.e. to paypal, or process the payment on the stores checkout in which case there are countless elements on the page from the merchants website. The error appears specifically related to the fact that the cookie contents is used as the basis for replacing content on the page, presumably assuming malicious code could be added to the cookie, but the contents is escaped? Mar 11, 2016 at 11:48
  • Heard back from the customer, he says they are applying for level D version 3.0. Mar 14, 2016 at 6:29
  • @JonathanHussey - Hmm. I've taken another look, and I have another guess. Try manually setting your cookie's value to ');alert('Hacked you! Level D shouldn't have any issues with injected content, but since your cookie is being injected into a javascript block, that's very different.
    – Bobson
    Mar 14, 2016 at 12:38
  • Would not htmlspecialchars() mitigate such an attack, so it would become ');alert('Hacked you!? I'll give it a go though. Mar 14, 2016 at 13:40
  • 1
    Yes that's a good call actually - I'll see if I can get in touch directly and find more specifics on why the fail is in fact a fail. Mar 14, 2016 at 16:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .