Security Blog

As developers, we are responsible for the following: Write clean, understandable, and maintainable code. Make code that speaks for itself. //AKA no comments Naming  stuff  👎   variables 👍 properly But we are only human, despite what many might think. We also made mistakes reflected in issues during our application’s usage. The dreaded bugs! And we can't avoid sometimes introducing them into our lines. However, there are a few practices that could help us reduce them. Security-First Mindset Let us try to keep at all times thinking like an attacker. Parameterized Queries: When interacting with databases or file systems, parameterized queries and prepared statements usage help prevent injection vulnerabilities, which can indirectly lead to IDOR issues. Context-Based Authorization: Consider the context of the user's actions and validate whether the request aligns with the user's role or privileges. Developers should avoid relying solely on client-side

As I dive deeper into security and research, I realize that understanding the correct terminology and tools for identifying vulnerabilities is crucial. I began by studying IDOR, a straightforward vulnerability. What is an IDOR vulnerability? An Insecure Direct Object Reference (or IDOR for short) vulnerability is a type of security flaw in web applications where an attacker can access or manipulate sensitive data or resources by directly referencing internal identifiers, such as database keys, filenames, and IDs, without proper authorization. In other words, the vulnerability occurs when an application fails to validate whether a user is authorized to access a particular object, and the attacker can exploit this weakness to gain unauthorized access. There could be two reasons behind the issue - either a logical error made by the developer who didn't correctly authenticate the user or displaying the identifier while connecting to the application host through a network. It is worth m