PCI & e-banking sensitive information tokenization/encryption/obfuscation - Which fields require to be secured?

Question

According to PCI standard all businesses that store, process or transmit payment cardholder data must be PCI Compliant.

Taking into account that we are talking about a bank, fields like card number and card holder's name should be obfuscated when displayed on the screen.

• What about the URL of the request? Is it acceptable to have a request like:

  https://myBank.com/cards/012345678901234/payment-third-party
  

  Where the card number appears as a path variable? (this is visible via F12-->Network tab - Not on the screen).

• What about the case the card number appears on the request payload:

  {cardNumber: "012345678901234"}
  

  What about the Network Tab (F12), is it acceptable for the fields to appear raw there, while they appear obfuscated on the screen?

• Regardless of the PCI standard, should the e-mail, tax id, physical addresses appear raw on screen? For security reasons, since this is sensitive information, they should be at least obfuscated. What about the Network Tab (F12)? Is it for the fields to appear there raw?

Answer 1

There are a couple of examples in your questions, some more concerning, some more benign.

Ultimately, you have to consider what's traversing a security boundary, is that necessary, and are there security implications.

As I mentioned in a comment, in general, being able to see or manipulate your own data in a browser's developer tools is not a security issue and should not be reported. However, does that mean that what you observed is not an issue? Not necessarily.

In reverse order:

Regardless of the PCI standard, should the e-mail, tax id, physical addresses appear raw on screen? For security reasons, since this is sensitive information, they should be at least obfuscated.

Probably not. It's up to the provider, but this is not generally information that is going to be at risk for shoulder surfing, which is why you would protect PCI sensitive data from view. Tax id possibly, but ultimately this is going to be up to either other regulations or the provider's best judgement.

What about the case the card number appears on the request payload

No, as I mentioned in another comment, data can't be sent without occurring in the request payload. Data in the request payload is effectively never a security issue. Not least of which due to the the fact that a request payload is arbitrary. A client can send whatever it wants to the server.

What about the URL of the request? Is it acceptable to have a request like:

https://myBank.com/cards/012345678901234/payment-third-party

This is the only legitimate concern I see here. And it has nothing to do with the request itself, but with the fact that request paths often are logged. If this is logged, then the provider would, in fact, be leaking sensitive data (the PAN, or card number) into their logs. It would be a significant enough leak that if I were the provider, I would create an incident to deal with it. If they are not logging the request path, there is probably no exposure, but this is probably worth reporting just in case.