Privacy and security considerations

Security is everyone’s responsibility

Anybody with access to, or even just knowledge of, an ecommerce site can affect its security — not only the people directly responsible for it. A common example: reusing the same password across your email, your store admin, and other unrelated sites. If any one of those is compromised, an attacker could potentially gain access to the others, including your store, and reroute sales or customer data to themselves.

This isn’t a hypothetical risk reserved for large companies. Sites of any size, including small stores, are routinely probed by bots looking for weaknesses, regardless of how well-known the business is.

Prevention is far cheaper than a breach: data breaches average $150–$200+ per stolen customer record, and state or federal fines can double or triple that figure depending on where your affected customers live and where your business operates. Basic habits — unique passwords, careful handling of admin access, and awareness that security isn’t solely someone else’s job — go a long way toward avoiding that cost.

Email address leakage during checkout

Because Foxy’s checkout automatically detects whether a submitted email belongs to a returning customer, it’s possible for someone to enter an email address and learn whether that address has a saved account — the checkout behaves differently for a new email versus a returning one.

This is a common tradeoff across ecommerce generally: the alternative is a much worse checkout experience, where errors can’t specify whether an email or password was wrong, leaving customers unsure which of several email addresses they used. An attacker would still need to already know the email address to test — this isn’t a way to discover your customers’ email addresses at large.

If you’re selling products where customer privacy is especially sensitive, you can avoid this entirely by forcing guest checkout only, so no customer email is ever saved.

Personal information in web receipts

Receipt URLs can be loaded without authentication. By default, though, receipts are set up so they aren’t revisitable — during a normal checkout flow, the browser history won’t let someone navigate back to view the receipt again. Any attack that got around this would require privileged access to the browser already, at which point the attacker would have access to everything else too.

A link to the receipt is included in the emailed receipt sent to the customer, but if an attacker has access to that email, they already have access to the same personal information the receipt would show.

If you want stronger control over this, you can configure your receipt template to output no data at all, and/or redirect to your own system using Foxy’s outgoing SSO functionality to handle the receipt display yourself.

Cart contents and JSONP exposure

Cart contents persist via a cookie, so on a shared computer, someone else using that machine could see them. If this is a concern, avoid using product options that contain personal information, or use the empty=reset functionality to clear the session entirely where available.

Separately, the /cart endpoint accepts JSONP requests without checking an origin or referrer header, meaning a malicious website could potentially read a customer’s cart contents. For this reason, avoid collecting personal information as product options.

Sending sensitive information over email

Email is not a secure channel unless it’s encrypted with something like S/MIME or PGP (GPG) — and in practice, almost nobody uses those. Treat all email as fundamentally insecure. A few reasons why:

• Email messages generally aren’t encrypted.

• Messages pass through multiple intermediate servers on the way to their destination, any one of which could intercept and read them.

• Many email providers keep backup copies of messages on their servers for months, even after the message is deleted from the inbox.

• Header information in an email can often identify the sender, even when anonymity is intended.

To put it concretely: a single email containing a credit card number can end up stored on, or passed through, the sender’s computer, the sender’s mail server, backup servers at that provider, roughly 6–12 intermediate mail servers, the recipient’s mail server, the recipient’s helpdesk or CRM system, and the recipient’s computer and phone. If any single one of those points is compromised, that data is exposed.

Never send sensitive information over email — this includes credit card numbers, passwords, Social Security numbers, or anything else that would be damaging if it fell into the wrong hands.

A note on TLS/SSL

Many mail servers now support TLS (or SSL), which encrypts email in transit between servers — but not at rest. Even when TLS is used, once an email arrives, it’s typically stored unencrypted on the mail server and in the recipient’s email client. Unless you know for certain that both your mail server and the recipient’s support TLS, assume the message isn’t encrypted in transit either.