One of the most important requirements to e-commerce is security. Unfortunately, there's no magic bullet that will make you secure, nor is there a way to fully outsource your security (though you can radically reduce your burden by using a hosted e-commerce platform like FoxyCart). This chapter exists to inform you about potential threats, common insecure practices, and best-practices.

One of the common complaints we hear from people getting started with e-commerce is:

I couldn't care less about this technical stuff. Security isn't my job! That's what I'm paying you for!

If only it were so easy. The simple fact is that anybody with access or even knowledge of an e-commerce website can potentially put the security of the entire system at risk. For example, many people use the same password for their email, website administration, and on random sites they visit. If any one of those sites is compromised, a malicious user could potentially reroute all your hard earned sales to their own bank account. So even though we at FoxyCart take our security very, very seriously, you could still create problems if you aren't familiar with basic security concerns.

Companies both giant and teensy get attacked every day. If you have a website available to the public, we'd bet dollars to donuts that it's getting attacked by bots on a daily basis. An ounce of prevention is worth a pound of cure, and a security breach averages between $150-$200+ per stolen customer record ^{1) 2)} (though various state and federal fines can easily double or triple that figure, depending on the residencies of the impacted customers and the nexuses of the breached company).

So, yes, we're paranoid. But that doesn't mean they're not out to get us all.

If you've been looking at e-commerce or gateway solutions for more than a few minutes, odds are that you've seen references to PCI DSS. While we can't give you specific advice relating to your own compliance requirements, we can help you understand some of the more important pieces of PCI DSS compliance.

First, it's important to know that the Payment Card Industry Security Standards Council (PCI SSC) is made up of the major card payment brands like Visa, MasterCard, AmericanExpress, and a few others.³⁾ They put together the Data Security Standard (DSS), giving us PCI DSS. There are a few different levels of PCI compliance, and determining your level of compliance can sometimes be tricky. The multiple levels of PCI compliance is further complicated by the considerable amount of FUD and outright misinformation that is used to try to make a sale, sometimes for a product or service that you may not need as a merchant.

The two “deliverable” requirements of PCI DSS are:

1. The Self-Assessment Questionnaire (SAQ), ranging from SAQ A through SAQ D. The SAQ A is very short, while the SAQ D has over 200 questions and requirements.
2. The Security Scan from an Approved Scanning Vendor (ASV).

You may be told by your merchant account provider or gateway that you are required to purchase a security scan through them in order to be PCI compliant, or that paying for a service will make you compliant. That is dangerously misleading information; simply paying for a service will not make you PCI compliant, as compliance can involve things like security training, paper shredding, and business policies and procedures that simply cannot be addressed by paying a 3rd party a monthly fee. So while the SAQ and the scan from an ASV are the pieces that are required to show compliance, they aren't simply things you pay for and magically become compliant.

Though we cannot tell you with certainty what your compliance requirements may be, we can offer a set of guidelines that may help you discern when you do actually need to pay for a service to become compliant (and conversely, when you're being sold misinformation or FUD).

If you're being told by your merchant account provider or gateway that you need to pay a fee to become compliant, be sure to understand the actual requirements. In many cases you may not need a scan at all, and your SAQ requirements may be quickly and easily completed without paying any additional fees.

Additionally, there are different merchant 'levels' that you should be aware of if you're doing more than 20,000 Visa transactions per year.

If you can limit your exposure to PCI DSS, we recommend it. Because there is no way to get a fully branded checkout experience without at least some level of PCI compliance, we generally recommend not using any virtual terminal functionality and completing the very manageable SAQ A. If you do need to use a virtual terminal, you'll likely be required to get a bit more advanced (possibly the SAQ D, though if you're using Foxy, many of the requirements won't actually apply). The one thing you really (really) don't want to do is store credit cards on your end, as the requirements become very complex and costly. And since FoxyCart handles this storage for you, there's little reason to spend the months or years and many thousands of dollars on becoming compliant at that level.

Your PCI DSS compliance will most likely be addressed when you set up a merchant account, though sometimes it will happen after the initial setup. As mentioned above, some processors have converted PCI DSS compliance into a profit point by tacking more onto the fees.

• Some processors charge $149 annual PCI compliance fee plus another $99 annual fee. (This is generally pure profit for the provider.)
• Others charge up to $19.95 per month on PCI compliance fees.

Again: Simply paying for a service will not make you PCI compliant, as compliance can involve things like security training, paper shredding, and business policies and procedures that simply cannot be addressed by paying a 3rd party a monthly fee. So if your merchant account provider or gateway tries to sell you on any services, make sure you actually need them (per the table above).

Breach insurance covers the merchant and processor in the event the merchant is PCI compliant but a breach occurs nonetheless. An example is a gas station with pay at the pump. Some people go into the convenience store to buy munchies and then leave the credit card at the counter to fill up the tank. That exposes the merchant to credit card number theft by any employees working behind the counter. This type of CC theft also happens very often in restaurants when waiter/waitresses carry the cards back to the cash register.

If you are concerned about this type of issue, your merchant account provider may be able to provide this for you. Our recommended gateway partner provides breach insurance included at no extra cost (so long as you keep your SAQ up to date, which they provide a tool to assist with as well).

Please read more about how FoxyCart is a PCI compliant service provider. If you yourself need to be PCI compliant at any level, you are required to ensure that your service providers are also PCI compliant.

If you're being told you need to be compliant and you don't have time to read all of the above, and assuming you don't process cards outside of your FoxyCart setup, here's the rundown:

1. Copy/paste this to your provider:

   We've outsourced our card handling to FoxyCart, which is a Level 1 PCI Compliant Service Provider listed on both Visa and MasterCard's registries. You can see their AOC here:
   
   https://wiki.foxycart.com/static/foxycart_security
   http://www.visa.com/splisting/
   http://www.mastercard.com/us/company/en/whatwedo/compliant_providers.html
   
   Do you still require that we provide proof of our own compliance? If so, do you have your own tool that we should use, or will providing the SAQ A be sufficient?

2. If they respond that they have their own tool, you should be able to fill that out. Otherwise, complete and send to them the PCI SAQ A. (Get the latest version from PCISecurityStandards.org directly.)
3. If they respond that you must be compliant at a higher level, or that they need proof of a passing security scan, or something else, please let us know.

We occasionally get emails like the following from FoxyCart users:

We got a call a day ago from a customer who stated that his AMEX had $4K of fraudulent charges. He said that after a purchase on our FoxyCart-powered site, his credit card details were taken and then used elsewhere.

FoxyCart goes through extensive security reviews and audits constantly. We have intrusion prevention and detection. We monitor the logs. We're proactive about security. We handle millions of transactions for thousands of merchants all over the world. We receive only one or two reports of a compromised card each year.

Though it's certainly possible we have a security breach on our end, it's far more likely that your customer's computer is compromised. The customer should wipe their computer, and/or toss it and get a new one.

Where FoxyCart has numerous safeguards in place, your customer's computer is a personal computer that may or may not be running antivirus and anti-malware. The customer uses it to browse the web and may not have the latest OS and browser security updates installed. The customer uses the computer to receive email, possibly on an older or unpatched email client. The customer's computer may be available to others (partners, spouses, children, friends) who visit questionable websites, download pirated software, clicked on an email attachment they shouldn't have, etc. There are myriad ways for the customer's computer to be compromised. Once that happens, as soon as they enter a credit card number anywhere (whether that's FoxyCart, Amazon, or their gas company's website), a keylogger can grab that, send it to the attacker, and their card is immediately compromised.

If this has happened to you or your customer and you'd like to loop us in to discussions, feel free. We take this extremely seriously. It's theoretically possible that FoxyCart had a security breach, and only one single customer was impacted, but the far more likely scenario is that the customer's computer has a virus or other malware. (We once had this happen where the customer said, “I never shop online because every time I buy something online, my card gets stolen.” The problem is obvious to those of us who've spent time scrubbing malware off friends' and family's computers, but the average computer user places far too much trust in their own computer's security.)

The most important misconception to address right off the bat is about email privacy and security. Simply put, email is not a secure means of communication unless it is encrypted via S/MIME or PGP (GPG). Even amongst people who know what those abbreviations actually mean they're not commonly used, for all intents and purposes you can assume that emails are fundamentally insecure.

Wikipedia has an in depth discussion of privacy and security relating to email, but here is a short summary of issues ⁴⁾:

• E-mail messages are generally not encrypted.
• E-mail messages have to go through intermediate computers before reaching their destination, meaning it is relatively easy for others to intercept and read messages.
• Many Internet Service Providers (ISP) store copies of e-mail messages on their mail servers before they are delivered. The backups of these can remain for up to several months on their server, despite deletion from the mailbox.
• The “Received:”-fields and other information in the e-mail can often identify the sender, preventing anonymous communication.

To drive that home, let's imagine a single email from Alice to Bob with Alice's credit card number in it. Once the email is sent and received, the credit card is either stored by or has passed through:

1. Alice's computer itself, keeping a local copy in the sent mail folder.
2. Alice's mail server (like Gmail, Hotmail, etc.), which keeps a copy in the sent folder.
3. Likely at least two or more backup servers at the mail service provider.
4. Probably about 6-12 mail servers in between Alice and Bob. (Connections aren't A to B on the internet, but rather hop along multiple servers.)
5. Bob's mail server.
6. Bob's helpdesk or CRM software's database, if applicable.
7. Bob's local computer.
8. Bob's iPhone, perhaps.

It should hopefully be clear that if any one of those points is compromised, Alice may now be dealing with an emptied bank account, overdrafts, considerable time wasted, and etc.

Even if your company manages its own mail servers, you trust your systems administrators with your life, and you maintain strong passwords and anti-virus protection on your computers, pay attention to the second bullet point there. In order to get from the sender to you, the recipient, an email bounces across many, many servers on its way. While it's doing this bouncing it is entirely unencrypted and can be intercepted. If one of those servers has been compromised it could be looking for emails coming through with 9- or 16-digit strings (social security numbers or credit card numbers, respectively).

Have you been emailing credit card numbers and passwords back and forth for years without consequence? Possibly. Should you continue? Not at all, especially not with any data belonging to your customers (as doing so violates agreements you've made with your merchant account provider at very least, and may violate state or federal laws depending on your location and the residency of the customer in question).

It should be noted that mail servers are increasingly supporting a protocol known as TLS (or SSL), which does actually encrypt email in transit, but not “at rest.” So the above example would change a little, and the email would be secure between Bob's mail server and Alice's. Unfortunately, not all mail servers support this, so unless you're sure that both your own mail server and your recipient's mail server support TLS, you should assume that they do not.

While TLS does help in transit, once an email arrives it is still stored in the clear on your mail server and (likely) in your email client (on your phone, desktop, or etc.). In some cases this may not be a big deal, but you still likely do not want sensitive information stored unencrypted.