3

I want to design Angular 6 application for PCI-DSS compliance. Is it a good idea to use it having in mind that this is a client-side application with a server back-end? Do you know if there any company which already uses it for applications with high security?

schroeder
  • 123,438
  • 55
  • 284
  • 319
Peter Penzov
  • 131
  • 2

2 Answers2

4

Yes, you can use Angular for a PCI certified/compliant application. I've done work for numerous level 1 PCI certified companies that use it. However, there are some different security concerns than a multi-page application.

You need to make sure that the server side code for your web service is secure, but all that that entails is a bit too much for the scope of this question. OWASP is a very basic place to begin: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project.

If your web service is on another domain, it must whitelist your Angular application's URL for CORS rules: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS. You may also have some strange interoperability between browsers if you have cross domain cookies. Test in all browsers, and ensure it works with strict privacy settings.

In the Angular application itself, first off, you need to make sure you don't persist sensitive information or PII in local storage, session storage, or cookies. Seems obvious: https://auth0.com/docs/tokens/concepts/token-storage#don-t-store-tokens-in-local-storage

You should also keep your session ID, authentication token, or whatever you use to authenticate to the web service in a secure only, HTTP only, strict domain cookie. That means the web service has to give it to the browser as such.

Next, you need to ensure you are handling XSRF. Angular has some built in functionality if you are on the same domain as your web service: https://angular.io/guide/security. There are numerous "gotchas" with that, so you may want to consider creating an interceptor that adds the XSRF to the request header of your API calls that contain user input.

Angular also has a lot of XSS handling built-in, but you should still filter for XSS server side. A PCI penetration tester is going to require that there is server side protection against XSS and other injection attacks.

Another gotcha that an auditor may bring up is if there's ever sensitive data in the address bar. I've been dinged for that on an audit, because the penetration testers said it could be cached or shoulder surfed.

It can be weird to think about the security of your JavaScript code, because for years we've always been told JavaScript has no security. I think that's what freaks out a lot of more veteran infosec people about it. I had a hard sell to some infosec people, because they weren't thinking about what a single page application really is. If you think of it as a multi-page application that loads only one time, and then only ever makes AJAX calls the transition for them may be a little easier.

Lastly, be sure to keep your framework, libraries, and other dependencies up to date. Check them against known vulnerability databases, and move off of any that are out of security support.

pumpkinthehead
  • 41
  • 6
  • Thank you for the information. What if I use server-side rendering? https://angular.io/guide/universal Should I expect issues like XSS, XSRF of some other issue? – Peter Penzov Dec 27 '19 at 09:16
  • Using Angular Universal shouldn't make a difference. Your API server will still need to check for the XSRF header and filter any input for XSS vulnerabilities on insertion to a database if applicable (if it will be used anywhere to generate HTML). This isn't the same thing as using server-side code to create templates as the documentation advises against https://angular.io/guide/security#server-side-xss-protection. – pumpkinthehead Jan 04 '20 at 00:26
  • @pumpkinthehead this seems like general information about securing a SPA. Could you go into more detail about handling data? Do you have to do anything special with the specific PCI data? Or does it not matter as long as you follow these guidelines? – iraleigh May 05 '20 at 17:26
  • @iraleigh I'm not familiar with all aspects of the tech stack, but I do know the database would have to be housed in a separate server than the application layer, and that it would have to be encrypted at rest. Ideally, the database fields holding personal identifying information would be encrypted and the drive encrypted, as well. Additionally, don't keep what you don't need. I've worked at some e-commerce shops that couldn't hold the card number, and I've never been at one that could store the CVV code. – pumpkinthehead Jul 15 '20 at 19:41
1

PCI DSS doesn't care about your framework, it cares about how you handle credit card details. It spans across your front and backend services. If you're not familiar with PCI-DSS the most cost effective way may be to use a third-party payment provider (e.g. PayPal) rather than implementing your own.

Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196