So we are reducing the criticality of an attack and that's a very, very important thing to do in the context of securing an application.
In this image, I'm using the HSTS, acronyms are really awful for non-natives anyway, I'm checking the strict transport security header with this service from Google. Here I've noticed that my company website was not properly configured. It's not a vulnerability, but still something I could improve to make my personal application more secure. So good progress. Let's go to number four, insecure design.
I really like this one because it's just that your code is bad and you should feel bad. It's quite wide also. Actually, not exactly your code, it's not your code that is bad, it's really the design, the architecture of your application that is in this vulnerability. The thing is that even though your code has no bugs, even if it's perfect, if the architecture itself is flowing, it's not working. It will lead to security flaws and breaches. So to avoid that, you might want to read articles about the best practices in HTS.
For instance, how to think about security in HTS from Sebastian Marpage, from the official Vercel team, of course. Some tips were separate data access layer, so you can isolate the code that communicates with your database in a specific area of your HTS application. That's a very good practice. It makes it easier to audit. It makes it easier to detect security issues. This is a good design that prevents security issues. You need to validate user inputs and more broadly, following the official learning resources will prevent bad design in your HTS application. You are going to write what we can call idiomatic HTS code. It's really important to understand how the framework designers are thinking about the framework itself, in order to use it the way they think you might want or should maybe use it. This way, you are avoiding a lot of mistakes that can happen.
Number three, injection. For instance, you let users post images. That's the basics of having a forum system or maybe a comment section in your blog. But instead of posting an image, the attacker will post a URL pointing to a script that collects cookies. Bad. Really bad. Because any user loading the image will get hacked. This is the kind of attack like supply chain, where the attacker will try to broaden the scope of the attack.
Comments