0

Quoting the OWASP Cheat Sheet on CSRF Prevention:

Using the Synchronizer Token Pattern:

CSRF tokens should be:

  • Unique per user session.
  • Secret
  • Unpredictable (large random value generated by a secure method).

As far as I can tell App Check is all of these. As I understand it, their token generation uses a server secret (though it may involve some frontend computation as well), which is then verified by the API endpoint.

Improve this question
3

1 Answer 1

Reset to default
2
+50

Based on the available documentation, no, it probably does not. Specifically, there is no indication that the App Check token is tied to a specific user, only to a specific app; another user of the same app could potentially pass App Check but cause the victim to send a request of the attacker's choosing within their own session, causing an attacker-chosen action to occur in the victim's account. This is what CSRF is.

With that said, it's unlikely to matter. CSRF is generally only relevant for apps where the client automatically sends tokens or credentials to the server with every request (or where the client is automatically trusted based on sheer ability to reach the server), and where outside apps can influence the client. In practice, that means specifically web apps, and only web apps that use cookies (or, in theory, HTTP authorization or client certificates) or where the authorization model is already dangerously open. Possibly there is a space in the overlap of reCAPTCHA Enterprise and App Check where CSRF is possible, but the primary use of App Check appears to be mobile apps, which are almost always going to fail one or both of the criteria above.

Improve this answer
4
  • We are in fact using App Check on a web app. I also implemented the Synchronizer Token Pattern, which is why I was wondering if I could safely remove it.
    – Joel Burget
    Commented Nov 23, 2023 at 0:09
  • The thing I'm confused about is that they require the use of an attestation provider (usually ReCAPTCHA Enterprise on the web, which is what we're using). At least in the case of ReCAPTCHA, a token would have to be tied to a specific user (though I don't see anywhere that explicitly says this).
    – Joel Burget
    Commented Nov 23, 2023 at 0:15
  • 1
    ReCAPTCHA ties its token to a particular page load, not to a particular user. ReCAPTCHA has no idea of your user model, and indeed is frequently used on unauthenticated pages - including sign-up and log-in pages - where there is no user (yet). However, in practice, tying a token to a particular page load is a viable alternative to tying it to a particular user, for the sake of defeating CSRF. Thus, you could, potentially, be protected here already. However, it's very risky to depend on undocumented behavior. Don't use a feature for security if it isn't known safe for that purpose.
    – CBHacking
    Commented Nov 23, 2023 at 6:17
  • 1
    If you want to avoid the costs of implementing your own CSRF solution based on synchronized tokens, there's a number of other options. The simplest, frankly, is not using cookies; if you're not automatically submitting credentials with requests (because they have to be added as e.g. Bearer tokens) then you're already safe from CSRF. Another option is requiring any header - even just Content-type: application/json - that third-party sites aren't allowed to set (without a CORS pre-flight that of course you don't permit).
    – CBHacking
    Commented Nov 23, 2023 at 6:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .