Do SPA applications have different security considerations than HTML5 sites?

Question

I'm looking into Single Page Applications that are used for both mobile development (PhoneGap) and regular websites.

Since the application can load from a offline copy, can run from http://localhost , or can be packaged as an app visible in the Apple App Store or Android Play Store (etc), the standard approach of setting credentials for the user and accessing resources is different.

Namely, Microsoft has a whole infrastructure that enables OAuth for native applications (though I don't see if/how they address SPA applications).

Question

• Are SPA applications more or less immune to CSRF, XSS, or other normal attacks?

• What about SPA applications embedded in PhoneGap, or some other app?

• Since SPA applications can read the REST data in the URLs passed to it, what protections are there from phone or normal web apps that respond this way?

• Are there misconceptions about how to do SPA applications that lead to security vulnerabilities? (I've often seen app developers ask how to use Javascript "encryption" instead of HTTPS here)

• Are authentication concerns different? (HTML5 Session usage vs passing parameters to the second SPA page)

I haven't seen much discussed about this new way of developing an application in light of security, and suspect that there are many security missteps here.

Answer 1

Are SPA applications more or less immune to CSRF, XSS, or other normal attacks?

Generally, no. The interaction between the client and the server should similar, if not identical to that of a plain-old-AJAXifed web app. You're still dealing with HTTP requests and responses that are coming from an untrusted client, and must according be treated carefully, but there's no particular additional risk that I see as a rule.

However:

There are two of the OWASP Top 10 that are potentially more likely to be improperly guarded against.

1) Sensitive Data Exposure

If you're not carefully about what data is contained by the initial page load, you could easily be sending data that shouldn't necessarily be exposed to all users. Because the entire page isn't generally visible in the browser in an SPA, this can lull a careless developer into a false sense of security.

2) Missing Function Level Access Control

In my mind, this is the big one when it comes to SPAs. Since you're moving functions and logic off of the server and out onto the client, it's very, very easy to provide a client with access to functions that he is not authorized to use. To some degree this can be mitigated by the fact that your data endpoints should also be separately protected and this should cause any attempts to use unauthorized functions to fail, but this is the one that gives me heartburn.

Are there misconceptions about how to do SPA applications that lead to security vulnerabilities?

Yes. A major misconception (by less security conscious developers, in any case) is that the application logic still belongs to you, and that you can rely on JavaScript in the browser for things like input validation and function authorization. As we all know, you can't. If it's on the client, it doesn't belong to you. Any validation and authorization that happens on the client is UX, not application security. Your endpoints on the server are ultimately and totally responsible for ensuring the security of the data and the application.

Are authentication concerns different? (HTML5 Session usage vs passing parameters to the second SPA page)

Not that I can think of. Remember, SPAs aren't a fundamentally different model, just a new way for allowing users to interact with a web application in a manner that takes advantage of modern browser capabilities to provider a better user experience.

Answer 2

I would argue that SPAs are more vulnerable to JSON Hijacking (which is a form of CSRF) because many of these applications rely on JSON to pass information. This is an attack that allows a a malicious site to retrieve and process data instead of the one way communication you typically see with CSRF.

Phil Haack wrote a great article that goes into more depth on how this works.