Is it possible to only use CSRF tokens on certain Server Actions? Or otherwise to exclude on certain Server Actions?
Reason: Some Server Actions are for non-browser requests
From what I've heard it's a global config, though I would've preferred a CSRF validate step, and one could put such in Globals steps...
Good question Apple, i was thinking along similar line, using CSRF tokens as an additional layer of security in server actions, checking the token as an additional condition within a query or using it like a security restrict
Yes @Apple, same for me… I have server actions that are webhooks from pre-webhooks-in-Wappler days.
I was already half way through implementing CSRF tokens manually anyway…
Lots of ideas about doing it manually here…
What type of request methods these external calls make, is this GET? Doesn’t it make sense to use API keys for this?
The CSRF protection is used for forms, which post data to your server actions.
That’s useful info @Teodor… so does this new feature not work for GET calls?
Not sure if you are familiar or how familiar you are when the CSRF protection is needed.
GET method is usually used to receive data, not to modify data on your apps.
CSRF tokens are usually associated with state-changing requests (such as POST, PUT, DELETE) rather than GET. The main reason is that the state-changing actions need to be protected against such attacks and it’s unnecessary for regular DB queries and GET requests because these operations do not modify the state of your application.
That’s why we have the GET method in the default excluded methods list in the options.
There is a global endpoint /_csrf that non browser requests can use to get the CSRF token first before making the requests. They do have to use the same session obviously.
In the next update we will also have a server action to generate the CSRF token in. Server connect action step so you can add fetch it as wel
Some are GET, some are POST. I use API keys but nothing Wappler built-in
Additionally @George, it's not feasible to modify existing clients to fetch a CSRF token first or use cookies/sessions.
I agree with @Apple,
@George @patrick , would it be possible to have a route exclusion list/setting for same, something like
csrf: {
enabled: true,
excludeMethods: 'GET,OPTIONS', // Methods to exclude from CSRF
excludeRoutes: ['/api/public', '/another/excluded/route'] // Routes to exclude from CSRF
},
Maybe we can add an option per route to exclude it from the CSRF validation @patrick
Here a small poll to get some feedback for a better implementation of the CSRF validation on the server.
Thanks for this team!
I need it in the PHP world for GETs too… there is a danger with CSRF of data being stolen as well as modified…
… and I have 10x more GETs than PUTs!
It is for Cross Site Request Forgery and not for protecting your API endpoints, using it for GET requests gives no extra protection. For protecting data you have the security provider and if your data is public then what do you want to protect?
CSRF protection is only needed for state-changing operations because of the same-origin policy. This policy states that:
a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin.
So the CSRF attack will not be able to access the data it requests because it is a cross-site (that's the CS in CSRF) request and prohibited by the same-origin policy. So illicit data access is not a problem with CSRF.
As a CSRF attack can execute commands but can't see their results, it is forced to act blindly. For example, a CSRF attack can tell your browser to request your bank account balance, but it can't see that balance. This is obviously a pointless attack (unless you're trying to DDoS the bank server or something). But it is not pointless if, for example, the CSRF attack tells your browser to instruct your bank to transfer money from your account to the attacker's account. The success or failure page for the transfer is inaccessible to the attacking script. Fortunately for the attacker, they don't need to see the bank's response, they just want the money in their account.
As only state-changing operations are likely to be targets of CSRF attacks, only they need CSRF defenses.
This topic was automatically closed after 32 hours. New replies are no longer allowed.
