1

I have two websites which do both accept payments on a subdomain. The subdomain is an independent system from the main website.

I have a question regarding the best practice to decide which of the following setup is the most secure (Of course, each individual website has to comply with PCI DSS etc. but this shouldnt be topic right now)

Version 1: Both payment websites are hosted on the same, independent server. I can see the advantage in being able to make the server more secure, as more unnecessary systems (e.g. webmail which is used by the primary website, ftp access etc) can be shut off, more stricter firewall rules can be established (e.g. no ftp, no port 80 connections etc, no email service). However, when someone manages to gain access to the server, he could tamper with both websites at the same time.

Version 2: Each payment website is hosted on the same server as the primary domain. The advantage / disadvantage are reversed compared to Version 1.

Is there a best practice? Do I assume that the risk of having both website hacked is minimal on Version 1 and thus the most favorable? Or is the risk of having multiple credit card processing websites hacked at once too high?

Thanks for your advice!

1

While there will be a lot of opinions around this, from a numbers viewpoint, I believe that having a common payment site independent from your other web sites is more economical and secure.

  1. Reduced attack surface. The single site should have a very simple API for your other sites to consume: "Customer X wants to pay amount Y for order Z", that sort of thing. This limits the possible ways for an intruder to violate the system. As you need to examine every single input for a flaw, there are simply fewer inputs to examine.

  2. Reduced audit scope. When you start dealing with payments, you must deal with PCI compliance. Payment systems are really onerous to certify. You don't want to have to pay the auditors extra to crawl over all your app servers just because they may have some payment data in them.

  3. A breach can easily be more disruptive than you imagine. If you're thinking that you're going to expose either X accounts hosting on one server each, or 2X accounts hosting on a common server, either breach has the potential to be so detrimental to your common business that both entities may go out of business entirely. Let's see if I can draw this:

    Number of     |
accounts breached | Progressively larger impact to business
                  |
    10^1          | Small fines, increased auditing
    10^2          | Larger fines, greatly increased auditing expense
    10^3          | Internet/Yelp impact to brand reputation, lawsuits
    10^4          | Local newsworthy impact to brand
    10^5          | Class action lawsuits, regional impact to brand
    10^6+         | National/international impact to brand

At every point on the scale your business' very survival is at increased risk. Would risking 2X accounts because you include two web sites change the potential impact? Not so much.

I think you're better off pooling your resources and securing a single payment site. And the more you look at this problem for smaller retailers, the more I recommend contracting with a payment gateway, and offloading that risk from your core business of selling widgets or gizmos. If a payment provider is breached, that generally won't reflect as badly on the web sites that used them. If it helps, think of the extra cost as an investment in reputation insurance.

Even if you choose to go with your "version 2", I would still recommend each web site maintain its own payment gateway as architecturally independent from the rest of the web site as possible. That means separate payment servers from the web servers, separate databases for payment data, etc., for the same reasons: to reduce the attack surfaces and decrease audit scope.

  • I appreciate the "graphical" explanation of point three which helped me a lot in the decision making. – Tom Apr 13 '17 at 21:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.