@JoeBetbeze

To put it simply: $guarded = [] (i.e. empty) tells Laravel that you do not want it to protect the app you are designing from mass assignment vulnerabilities. In other words, you are fully taking on the responsibility yourself of preventing anything from being mass-assignable.

So Jeffrey is showing us here how to use mass-assignment "within tinker" while developing an app/site (a way to quickly whip up a new 'whatever you need'), but he is also showing us that the "best" way to avoid such potential vulnerabilities is to never use mass-assignment "in the app itself" with anything that is even remotely user generated or user editable. In other words, $guarded = [*] will certainly kill mass-assignment for anything in the app, but it will also prevent you from using mass-assignment within tinker, where it is strictly within full control. Tinker provides a massive productivity boost for developers, so you probably don't want to artificially limit its abilities that way.

My own suggestion would be to use either a populated $fillable or populated $guarded property in your apps for however long it takes to gain full confidence in your ability to recognize mass-assignment-based code (at which point, maybe you then decide to turn off that protection with an empty $guarded array, so you can still use fully developer-controlled mass-assignment in tinker or elsewhere).

In other words, be patient through the learning process, especially with yourself. Don't sweat the small stuff. And then of course there's Rule #2: It's ALL small stuff (if you allow it to be). ;)

3 Ways to Mitigate Mass Assignment Vulnerabilities

Updated Series Available