Angular, React, Vue & headless; Are you also leaking?
The good old days. I still remember what I did when I started my first gig. Just basic programming; frameworks even for “server-sided” languages hardly existed. Let alone frontend. I guess I did the same what most of us did, just pumping out new websites for customers or ourselves. Things were easy then, at least below the line. The horror was to make a website compatible with every browser. We still had Internet Explorer 6 which was broken by default. We had to use some hacks because IE6 was not compatible with transparent PNG’s. Yea..those days.
What I actually meant by “below the line” is that we had to worry about some issues when building an application or website. After that was done; everything was done. Nowadays security is a hot topic. Privacy goes inline with that. I guess people saw the profit into automating the process of exploiting, hacking and gathering information. After the years went by when we buried IE6 we also see a shift in the quality of websites, security, privacy. Hell, we even have real “privacy and security officers” for companies.
I really embrace this shift, there is nothing bad or wrong here. The thing is tho, we barely manage our current techniques. SQL Injections are still very much common. New programmers might only have learned 1–2 years ago about MySQLi, the improved database extension for PHP. It provides a much securer way for people to handle database connections. If you browse the web for questions regarding PHP + MySQL you will still see bad examples providing direct MySQL Injections using the old MySQL extension. I’m not about discussing this but it is an example on the current status. Just replace MySQLi with any other technique/lib/class/whatever.
It’s only recently that major browsers added security for blocking XSS (cross-site scripting). SSL / HTTPS is finally becoming a standard rather than something “fancy”. I can go on, but only baby steps have been made and so many people and companies are still adjusting to this shift to make secure applications. And now when we are finally making some progress we see something new popping up in production. Headless.
I guess I can be fairly short about Headless applications. Headless means it has no head. It has no graphical interface. We have to attach this head, in my title I mentioned a few names; we need something “frontendy”. From what I see most people pick either Angular, Vue or React for this. I cannot blame them. These are awesome frameworks. Yet these are also the techniques used to leak the shit out of privacy information. I’m not saying they are the cause. Just remember that ;)
So this headless application needs to be “used” by a frontend. An easy way is an API. Simply make a request (/get/users) to your headless application and we get a JSON (or whatever) result back including all our users. Now we can use this object of users in our frontend. Easy peasy (right..?). Depending on how the API is made we can also just query for stuff like /get/user/John and we would receive John’s information. These requests are actually just calls made by you. Please remember that something “frontend” runs on your browser. So yes, you request https://the-domain-of-the-headless-app.com/get/users by yourself.
This is one major key so many people are missing out. If a user can request /get/users and get every user in the system: Your application is flawed and insecure. There needs to be proper authentication and proper scopes in which a user can query for information and for obvious reasons only his/her’s information.
And this is hard. When programming on something that does not see the daylight unless you specifically force it to “output” you can do whatever you want in your logic. When the backend also controllers the frontend you can specifically tell what you output and what not. When using headless you sometimes add logic to your frontend which might cause a huge fallback.
A basic example which I have seen numerous of times in real production environments of pretty big websites:
- The user wants to register
- User inputs an e-mail address -> request to the headless backend
- Backend returns a JSON request:
“result”: {
“email”: “foo@bar.com”,
“in_use”: true,
“user”: someusername
}Well, there goes your security.
You know security through obscurity? Basically, when I use an application I want to see one of following messages:
- Wrong password or username
- Bad credentials
- Wrong login
but absolutely not:
- Bad password (so username/email is right)
- E-mail address is unavailable, it is used by username: foobar!
- Ah sorry, but that password is already used by email address foo@bar.com
If I type it like these lines, everyone agrees. Did you know if you open your browser’s console there is a great chance you can see these results from this headless application XHR requests & responses?
I get it, we want to move forward. There are so many advantages of headless if used correctly. The downside is that I expect so many leaks, so many hacks and so many issues just because of using new techniques without actually fundamentally understanding them.
It has taken me a small portion of an evening in which I found various headless applications leaking sensitive information. Yes; I have notified them all.
Why are we so much focussing on various things like speed, performance, usability, ease of development, staging servers and a huge base of libraries. Yet we do not even have something that just checks every endpoint of your headless app for potential “unauthorised” information leaking?
I guess it takes an other 3 years before this becomes a basic in headless, an other year before people actually follow up on it. By the time we can finally deploy stable and secure applications we probably have a new technique making the web unsafe again.