Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
add comment

2 Answers

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.

share|improve this answer
    
One thing that comes to mind when reading this is many developers have posted application secrets directly into an SPA (Facebook authentication key, or Twitter private key) and not realised the source was available to attackers. –  makerofthings7 Aug 26 '13 at 17:03
    
@makerofthings7 Yup, this is the issue that I mentioned in response to your second question. Inexperienced developers often don't understand that the critical trust boundary is between the server and the client, rather than between the user and the application. –  Xander Aug 26 '13 at 17:14
1  
@makerofthings7 As an aside, native applications often have the same issue. Developers have an unfortunate tendency to think that because they've "compiled the secret into the app" that it's somehow magically safe. It's the same general principle in either case. You can't trust anything that's out of your direct control. –  Xander Aug 26 '13 at 17:46
add comment

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.

share|improve this answer
    
All modern browsers have protection against JSON Hijacking. While having application-level protection won't hurt, it isn't really necessary now. –  paj28 Oct 23 '13 at 2:06
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.