Hacker News Reader

> One thing I've been seeing recently is that some implementations using Stripe DO have the CC details hitting their server. The most common case being when Javascript is disabled the form posts to the website because the developer didn't design with graceful degradation, a dangerous mistake when mixed with credit card numbers.

Only if you do it wrong. From the Stripe docs: "The only thing to note is how input fields representing sensitive card data (number, CVC, expiration month and year) do not have a 'name' attribute. This prevents them from hitting your server when the form is submitted."

> It doesn't appear to be a problem for you (your payment page for CC info doesn't gracefully degrade with JS disabled and is impassible - you might want to fix that!) but I've seen it on other sites, and it's especially a problem when other sites don't use SSL as a fail safe for this sort of case which I have also seen.

Again, SSL is covered by the docs. Stripe says you need it. Not that you should consider it, or that it's a bonus, but that you need it. https://stripe.com/help/ssl

Can't they deny all requests from non HTTPS pages then?

No, I think there is no way to detect if the HTTP-request to the server which makes the API call is made via HTTPS or not. Except if their libraries detect that on your side and block the API call there, but of course that can be easily circumvented. They can only enforce that HTTPS requests are made to their API.

Detecting it on your side and blocking the call there would still be really useful. Most people who use HTTP instead of HTTPS probably do so by accident or out of ignorance, and detecting that during development and telling them to fix it would be useful.

Yeah you are right here that it is still possible for our users to mess things up. We do things to try to keep merchants from accidentally sending card numbers to their server (e.g. the default example form makes this hard to do, and most people simply copy and paste this form). It's an explicit decision we've made, though, to leave control in our users' hands as many people seem to like the flexibility to have their checkout experience stay on their site and be designed by them. But we think about where to draw the lines here a decent amount.

I worked on something with credit card processing a few years ago. As I remember, it doesn't really matter if the details hit your server, but the point is you absolutely can not save them.

No putting them in a DB, no putting the in a log file (not even the last four or something like that), nothing. So if your form takes the numbers in, you make an API call, and then you blank them in memory you were OK.

If you put them in the user's session, you were in trouble.

It's all insanely complicated, and the only good solution is "don't do it." There's a good reason people use things like Stripe, PayPal, Authorize.net's CIM (where they store it and certify that they are PCI compliant).

To make sure there isn't confusion here, having card details go through your server, even if you aren't saving them, still can lead to certain PCI compliance burdens (e.g. you may need to get an audit from a PCI auditor verifying this).

Having the card never go to your server is the best way to make sure you are PCI compliant, as you mention.

Ah, thanks. Like I said, I wasn't sure. We made sure we were PCI compliant, but I wasn't in charge of that by any means.

One component is the transit security -is the data safe from interception in transit (on the network). The other component it security of the data at rest - is the data safe from interception if it comes to rest on your server (sessions, databases, etc.).

From data security standpoint is is easier to let somebody else do it, but end users tend to have a less satisfying checkout experience.

This is wrong. You still need to be PCI compliant even if you don't persist the CC data. There are a few bullet points you don't need to worry about in that case, but the vast majority still apply if the system has anything to do with credit cards (such as the details hitting your server).

Please read stripe's TOS - your application is REQUIRED to be PCI compliant.

I think I know why I got this wrong. There are multiple levels of PCI compliance, right? I think we used services that allowed us to not have to be compliant with data at rest (since we didn't store it), but only the data in transit (or whatever the equivalent term is).

This is by no means my area of expertise (as I have accidentally proven).

Absolutely, there are different levels. However, for all levels you have to do some work to achieve PCI compliance (and overall security of your system). There is no magic in this world :)

True, and the thing about PCI is that many apps probably could benefit from being forced to do this type of work.

It's worth noting that we're talking about "degrees" of PCI compliance vs "I'm on the hook or I'm not on the hook" Implementing Stripe so that the data never touches your servers still requires you to complete a SAQ-A. That's just a LOT easier than if you are handling the data and have to complete a different SAQ.

there is no magic in this world (even if stripe's marketing team wants you to believe that there is)