Security Tip: Sensitive Model Attributes
[Tip#8] We need to be careful of sensitive data and where it gets passed around, especially when it relates to models and Javascript.
I hope you found last week’s In Depth email interesting (Escaping Output Safely), and had some fun with the XSS demo. If you’re interested, I wrote a Twitter thread covering how I built the intentionally vulnerable demo app, to go along with my previous thread about securing the hosting for it.
This week I have a quick security tip for you (scroll down to the code blocks if you’re busy). It is a very useful security feature if your database models are passed into javascript or over an API.
Securing Sensitive Model Attributes
Traditionally our database models are stored and contained on the server, and we can throw whatever data into them - including sensitive data. However, javascript frameworks like Vue.js, Inertia.js, and even Livewire, make it easy to interact with your models directly in the browser, and if it’s in the browser, it’s publicly visible.
It’s not just javascript frameworks which will do this too! I recently discovered one of my models was leaked on a page in my app because I had passed it into a Blade component, but forgotten to tell Blade it was a prop, not an attribute. So Blade treated it as an attribute and serialized it into the HTML!! It’s super simple to accidently sensitive leak data through models if you’re passing them around the view or javascript layers.
The risk here is simple: if you store sensitive data on your models and send these to the browser, it may end up in the browser, and someone could find it1.
We’re talking about password hashes2, dates of birth, API keys, secret messages, staff comments, etc. The list goes on and on… Basically anything that the person making the request shouldn’t have access to.
Keep reading with a 7-day free trial
Subscribe to Securing Laravel to keep reading this post and get 7 days of free access to the full post archives.