Hello,
I have read the Livewire documentation again and I notice that it is never mentioned something about @csrf.
What about security using Livewire components ?
I mean ... without csrf token, it is possible to send datas to the server and save them into the database.
Perhaps I don't known enough about csrf and other security problems.
Would it be a good idea and secure to develop a while website with only Livewire components (that means with authentication form also) ? Is it secure to integrate only a few Livewire components in a traditional blade front ?
Well I have several questions ... perhaps other questions after your answers ... if someone could explain me if and why Livewire is less or more or equal secure than without Livewire.
Thank you for your help ;).
Vincent
Livewire uses a checksum to ensure that state passed between the frontend and server are consistent. Without this checksum passing, Livewire will reject the Request.
This is not exactly like CSRF, or what CSRF is intended to achieve; but CSRF does not prevent bad data.
Ok ... thank you.
What do you mean about bad data ? Do you think about sql queries for example ?
I mean ... without csrf token, it is possible to send datas to the server and save them into the database.
This.
I don't understand what you mean. You have written => but CSRF does not prevent bad data.
Because it doesn't.
While it looks like it is undocumented, Livewire does indeed prevent CSRF attacks. If you look at the requests Livewire does you can see the X-CSRF-TOKEN in the header, and if you remove that token the request is denied.
That's interesting ...
Hey everyone,
Lets stir things up for the weekend! So is it really, really secure or we are missing something? I found this article mentioned somewhere else by @Snapey https://forum.archte.ch/livewire/t/advanced-livewire-a-better-way-of-working-with-models
Samuel claims in it that we can simply swap id's and edit someone else post and so on.
See this: https://twitter.com/archtechx/status/1448758312611233794
Livewire doesn't let you directly change the serverMemo data, since it's verified via that checksum. But you can >change anything in data via the JS runtime which pushes the changes using $set.
If you couldn't modify data on the frontend, then the Alpine integration wouldn't work — @entangle couldn't >work, the $wire proxy wouldn't work — and you couldn't use $set() in wire:click handlers.
This is a common misunderstanding which is why I covered it in the first part of this series. Everything in the >component's data can be modified on the frontend — even if it's not used in any wire:click handlers or other >things like that.
I personally would use random uuid for my models so thats not that much of a concern but even if I did not Author seems to forget that you an actually do the same thing with any Laravel route and Controller in traditional application and you should protect yourself against it by validating data using gates and authorisation.
So what am I missing in here? Is it less safe out of the box then regular Laravel app or is it not?
Thanks!
@aurawindsurfing what he means is that suppose you have a model id as a public property on the Livewire component. That id can be manipulated from the client.
If in your component, you hydrate the model using the id so that you can apply data and save it, then you could be tricked into updating the wrong model.
So, like in regular controllers, you should check that the user is allowed to access or change the model, on every update, not just when the view was first loaded (in simple terms)
@Snapey Yeah exactly so it does not differ from a user manually changing url and trying to access another users profile. Simple Model Policy solves that issue.
As per documentation: https://laravel-livewire.com/docs/2.x/authorization
@aurawindsurfing if people remember to enforce it in the Livewire component
@Snapey true but same goes for regular route/controller, I see no issue here.
@aurawindsurfing im making a video, watch this space
changing url and trying to access another users profile
Look how laracast does as example my participation, in the background the auth id is used it's not in url.
@jlrdw yes that was just an example. What I mean that Model policies will work as expected in Livewire just people need to implement them
@snapey Where can I see your video? Most of this discussion is over my head. Thanks
@nategg its here, but Livewire3 has new protections you can use
@Snapey Thanks much. Very enlightening. Never seen it done or explained properly before.
@Snapey Yes I'm just transitioning to Livewire3. I'm about to post a question (double) about it on the forum.
In Livewire 3, you can use #[Locked] to prevent property modification on the front end: https://livewire.laravel.com/docs/locked. The most suitable target is to lock the ID property of the model.
However, this doesn't exclude the fact that a proper policy/gates should be added.
@Merklin I you are using model binding, the id of the model is automatically locked without need to specify the locked attribute, but it's necessary to specify this attribute for the other properties if needed.
Please or to participate in this conversation.