Showing results for 
Search instead for 
Did you mean: 

SIM x_header_html_xx broken with IE8 XSS filter

Similar issue has been posted on this forum but was never addressed properly by Authorize.Net. I called the support and the answer is a very disappointing "IE 8 is not yet supported". I then questioned about the list of officially supported browsers and the support could not give such a list. With all the new windows 7 come packed with IE 8 already, more and more people will be using IE 8, I don't not think it's a responsible answer from Authorize.Net, at least it's a slow response to its customer, especially consider how simple the solution is.



Any way, here is the problem description, followed by the solution that Authorize.Net needs to implement (Google did this).


[The Problem] 

Due to the 255 char limit when trying to set header / footer on the merchant settings page, many times the only option is, and this is recommended by Authorize.Net, to use the form post API with the following parameters:


It works for all major browsers, except IE 8. IE 8 added a new XSS (Cross-Site Scripting) filter which is turned on by default. This filter is triggered for SIM because:
- Payment form page and the post target URL are from different domain
- Posted data appears unchanged in the returned response page (the HTML data we set are echoed back by Authorize.Net untouched)



So what you see is that the HTML content you posted over using the above parameters are commented out by IE 8, and even worse is that IE 8 display a message saying "Internet Explorer has modified this page to help prevent cross-site scripting." Making your site seems contains malicious code.



[The Fix]

The fix is actually fairly simple, but it needs to be applied by Authorize.Net:
On the payment page, set this HTTP header (published by Microsoft):
  X-XSS-Protection: 0
This will disable the filter for the payment page.



I don't think there is any work around. The best you can do before Authorize.Net fixes this is to shrink your HTML to fit the 255 limit. Meanwhile, try your best to push Authorize.Net to fix it.



BTW, one answer I received from Authorize.Net support was that: "This is a Microsoft issue, please contact them to get it fixed." Well, if Authorize.Net don't plan to support IE 8, sure.


Since there is no way to submit support ticket, I am using this thread to keep track of the issue.


An update. The support asked me to email developer to have this issue addressed. So I dd and the response I got is:

From developer:

I’m unsure as to why the support representative advised you to contact me. I will not be of assistance in relation to this matter. XSS is a feature of IE8 and can be turned off by each user in their browser settings.


And my reply to it is:

It’s true that XSS can be turned off, but average user who goes through SIM may not have the necessary knowledge on what is happening and how to turn it off, as she only sees the security warning. Besides, when the user sees this security warning, she most likely would think the payment service might be unsafe to use or has been compromised, and choose not to proceed, which will hurt your revenue as well as the merchant’s.


I think at least should have a new account setting to resolve this issue should merchant choose to. When this options is checked, the payment page will be served with an additional HTTP header (X-XSS-Protection: 0) to disable the XSS filter for the payment page only.


The reason that the support routed me to contact developer @ is because this issue can only be addressed by your department. I think this is one of those issues that requires a careful evaluation on its impact to your business before simply reply with a “no, we will not do it” answer without much consideration. As I pointed out earlier, this hurts both the merchant and adversely.

I think I should emphasize that this has a very bad impact to the merchant as well as business wise: How likely will you proceed to give out your credit card # after you see an IE security warning about "Cross-Site Scripting" during your check out? And if the user does not pay, merchant doesn't get paid, and doesn't get paid neither!



Same problem here. IE8 outputs the XSS warning when I try to add a background image by styling the body tag:


<INPUT TYPE='hidden' NAME='x_header_html_payment_form' VALUE='<style type=&quot;text/css&quot;> body{background:#B5D894 url( repeat-x;}</style>' /> Could you guys please support IE8 and set the header "X-XSS-Protection: 0" as described on this 1-page Microsoft pdf file?


I want to bump this thread again.


Is there any response from on dealing with this issue?


Has anyone come up with a workaround for the problem?




I was running into the same issue as above, however, I was fortunate enough to workaround it using the method below.  This may or may not work depending on your requirements for the header/footer but thought I would share.


97% of what I was sending in the header was CSS to style the SIM checkout page.  The rest of the header text/links/etc I was able to minify enough to fit within the 255 character limit of the settings.  The css was then moved into a separate file hosted on my secure server.  In the footer form settings, I simply link to this CSS file to pull it in.

Anyone else have any thoughts about this?  I am having the same issue.  Unfortunately, I need a solution that would allow me to use different CSS, etc depending on which where the checkout page is coming from...  so putting the content into the Merchant Interface doesn't work for me.

I'm having the same issue. 

I'm hoping there is an updated status?

I've had the same issues with my client.  We have more CSS customization needs than the 255 merchant account interface fields allow, but including the CSS with the transaction variables or specifying a stylesheet on my server (referenced using HTTPS) yield cross-site scripting errors in IE.


I opened a support ticket, and received the following reply:  "I understand you need to be able to have a header that contains more then 255 characters.  I am sorry that isn’t an option with SIM.  That is one of the limitations with using our SIM integration.  If you need to use more than 255 characters you would need to use our Advanced Integration Method (AIM).  With AIM you would host your own checkout page under your own secure server.   With you hosting your own checkout page you will be in more control over limitations like this."


Obviously, one of the biggest reasons for using SIM is to avoid PCI compliance responsibility/issues, and but for the 255 character limitation (or a suitable workaround, like letting users upload a stylesheet to's servers, like they allow with images), it would really be a complete alternative.  Furthermore, the new Direct Post Method isn't really an option either because (as confirmed with a PCI compliance agent at's partner TrustWave) the form into which the customer enters their card information is still served by the merchant's server.  Even though it submits directly to, you still have a lot of the PCI issues because an attacker could compromise the merchant's server and change the target of the form.


Basically, as others in this thread have discovered, isn't prepared to offer a solution for this.  I'm not sure if it'll do any good, but I suggest that if you have this issue, let know about it and maybe we can collectively influence the development roadmap to include a fix.


Good luck everyone.




hey guys. Just wanted to drop a quick thanks in here. This helped me resolve my problem.


For me it was simple since i don't actually use the headers/footers capability but when i originally designed it i thought i might so i included the framework for it and just never defined the header stuff. The strange part is that i was basically passing nothing. The code below is a summary but you get the idea.


global $paymentHeader; // this breaks it

$paymentHeader = ''; // this fixes it.


echo " body{width:$width; font-family:$fontFamily; font-size:$fontSize; margin:$margin; margin-top:$marginTop; background-color:$bgColour; color:$fontColour} $paymentHeader\" /> \r\n";


hope this helps someone.

Has addressed this issue by now???