Secure tunes
The caching strategy for The Session that I wrote about is working a treat.
There are currently about 45,000 different tune settings on the site. One week after introducing the server-side caching, over 40,000 of those settings are already cached.
But even though it’s currently working well, I’m going to change the caching mechanism.
The eagle-eyed amongst you might have raised an eagle eyebrow when I described how the caching happens:
The first time anyone hits a tune page, the ABCs getting converted to SVGs as usual. But now there’s one additional step. I grab the generated markup and send it as an Ajax payload to an endpoint on my server. That endpoint stores the sheetmusic as a file in a cache.
I knew when I came up with this plan that there was a flaw. The endpoint that receives the markup via Ajax is accepting data from the client. That data could be faked by a malicious actor.
Sure, I’m doing a whole bunch of checks and sanitisation on the server, but there’s always going to be a way of working around that. You can never trust data sent from the client. I was kind of relying on security through obscurity …except it wasn’t even that obscure because I blogged about it.
So I’m switching over to using a headless browser to extract the sheetmusic. You may recall that I wrote:
I could spin up a headless browser, run the JavaScript and take a snapshot. But that’s a bit beyond my backend programming skills.
That’s still true. So I’m outsourcing the work to Browserless.
There’s a reason I didn’t go with that solution to begin with. Like I said, over 40,000 tune settings have already been cached. If I had used the Browserless API to do that work, it would’ve been quite pricey. But now that the flood is over and there’s a just a trickle of caching happening, Browserless is a reasonable option.
Anyway, that security hole has now been closed. Thank you to everyone who wrote in to let me know about it. Like I said, I was aware of it, but it was good to have it confirmed.
Funnily enough, the security lesson here is the same as my conclusion when talking about performance:
If that means shifting the work from the browser to the server, do it!