Will my secure site pass credit card PCI compliance scans?

This page is showing a generic answer.
To see a more detailed answer customized for you, type your domain name here:

If you accept a large volume of credit cards, your site may be required to pass a PCI scan or a similar “security vulnerability” scan.

Our servers are configured to help you pass these scans. We have many customers who are regularly scanned without any problems.

However, you may need to ask us to make some minor changes to the way your site is set up before a scan.

On this page:

SSL certificate

First of all, you’ll need your own SSL certificate. A free certificate we offer should work fine.

You may also need a dedicated IP address in some cases (explained below). A dedicated IP address costs an additional $2.00 per month (per domain name).

Disabling old TLS protocols

Some PCI scanning companies require that you disable “TLS 1.0” and “TLS 1.1”. You can do this in our control panel:

  1. Login to the “My Account” control panel (having trouble?)
  2. Click SSL Certificate
  3. Scroll down the page to the bottom of the “SSL/TLS protocol version settings” section
  4. Click show protocol options
  5. Choose TLS 1.2 or 1.3 only to disable TLS 1.0 and TLS 1.1

Disabling FTP, SSH and remote MySQL connections

Some scanning companies require your site to reject certain connections. We can do this for you if so (you’ll need a dedicated IP address for an additional $2.00 per month).

Specifically, some companies require your site to reject FTP connections. To help you pass the test, we can block access to FTP (ports 21 and 20) at the firewall level for your site’s IP address if you contact us. (You’ll still be able to access FTP via the ftp.tigertech.net hostname.)

Also, if you don’t use SSH connections, we can block SSH access (port 22) from outside our network at the firewall level.

Finally, if you make sure that remote MySQL connections are not enabled for any of your databases, we’ll automatically block MySQL access (port 3306) to your dedicated IP address at the firewall level.

SSL ciphers and the “BEAST Vulnerability”

One customer reported that their PCI scan company complained about a possible “BEAST (Browser Exploit Against SSL/TLS) Vulnerability” problem.

This isn’t actually the case, so if this happens to you, you should be able to successfully appeal it by sending the company this text:

This server is not vulnerable to the BEAST attack because it prefers RC4 ciphers over block-based ciphers. This can be verified at <https://www.ssllabs.com/ssltest/>, which shows "BEAST attack Mitigated server-side".

We’ll be glad to talk to your PCI compliance company if they still have a problem with it after seeing that.

SSL ciphers and the “SWEET32 Vulnerability”

One customer reported that their PCI scan company complained about a possible “SWEET32 Vulnerability”, aka “CVE-2016-2183”.

This isn’t an actual risk, because the “vulnerability” can only be used if the server doesn’t limit the number of “keepalive connections”, and our servers do.

However, you can avoid having your PCI company think this is a problem by choosing the High security SSL option in our control panel, which disables the “3DES ciphers” that they are looking for.

If you can’t use “High security” settings, you may be able to successfully appeal it by sending your PCI scanning company this text:

This server is not vulnerable to the CVE-2016-2183 "SWEET32" attack because it limits keep-alive connections to 100 requests, then resets the connection. This prevents attackers from sending the necessary data to take advantage of this vulnerability.

X-Frame-Options response header

Some PCI scanning services report that “The remote web server does not set an X-Frame-Options response header or a Content-Security-Policy 'frame-ancestors' response header in all content responses”.

If they say this, they want you to add one of these headers so that the site can’t be embedded in another site’s frames. You can do this by adding this line to your site’s .htaccess file:

Header set X-Frame-Options DENY

We can do this for you if you wish; just contact us.

WordPress User Enumeration

If you use WordPress to run your website, some scanning companies will flag a WordPress User Enumeration vulnerability. What they mean by this is that it may be possible to visit URLs like http://www.example.com/?author=1 to discover the WordPress username, even if it’s not the default “admin” username.

You can fix this by adding these lines to your site’s .htaccess file:

RewriteEngine On
RewriteCond %{QUERY_STRING} ^author=([0-9]+)$
RewriteRule .* - [forbidden,last]

Again, we can do this for you if you wish; just contact us.

Setting the “secure” flag on all cookies

If your PCI scanning company says that your scripts are not correctly setting the “secure” flag on cookies that they send, you can force your scripts to do so by adding this line to your ”php.ini” settings:

session.cookie_secure = 1

HTTP request smuggling

Some PCI scans ask you to check that the server is not vulnerable to HTTP request smuggling. You can tell your scanning company that your site isn’t vulnerable to this, both because there’s no separate backend server that’s different from the frontend server (so there aren’t two systems that use HTTP/1.1 vs. HTTP/2.0, or that can parse the “Transfer-Encoding” or “Content-Length’ differently), and because we have mitigations in place (including using the Apache web server HttpProtocolOptions Strict option by default).

Can you certify that my site is PCI compliant?

Since we don’t provide any credit card handling services to customers, we can’t certify that the way you use our service is PCI compliant. In other words, while it’s possible for you to use our service and be compliant, using our service doesn’t automatically make your site compliant.

Your PCI provider may require you fill out a questionnaire each year verifying that the server that hosts your site meets some specific requirements. For example, they will require you to use servers that implement firewalls, require that all software receives regular security updates, and so on. We believe that we meet those requirements (our own site passes monthly PCI compliance scans and annual self-assessment questionnaires from Comodo HackerGuardian), and will try to answer any specific questions you have about them.

But that’s only one piece of the puzzle. Ultimately, it’s credit card handling software that you install and control on your site that determines many of the compliance details. When you install software like that, you’re taking responsibility for making sure it follows all the rules.

If you’re looking for a hosting company that handles everything related to accepting credit cards on your site, and is PCI-certified for that purpose, we’re not the right company to choose. You should instead search for ecommerce-specific hosting companies that include credit card handling services and therefore manage your site’s PCI compliance.

Note that most security experts strongly recommend that you don’t collect credit card numbers using software on your own site, instead outsourcing that part to a service provider. We agree with that advice, unless you have technical expertise in web script security. Handling credit card numbers in a secure manner is difficult and requires constant security monitoring. If you let a service provider handle it, you’ll still have to pass PCI compliance scans, but the questionnaire you’ll need to fill out is much simpler.