These are the top 10 ways that tech entities get hacked. You'd be surprised at how many hacks are unsophisticated and relies on some kid typing in "solarwinds123" as a password.
As a developer, we study and learn how the most common hacks work in order to prevent them, but for my brocels, who am I kidding? Whether you want to build a hyper-secure incel chatroom, or want to hack some femcel websites, I cannot stop you.
All I am doing is providing what is already widely known, and actively posted by reputable organizations; there are more hacks not listed here, so these are the most common ones.
I will use OWASP Top Ten Web Application Security Risks and provide real case study examples; the legacy (frameworks not updated since 2018) apps in the company I work at exhibit all ten of them, so I know some real examples (I will fictionalize them for OPSEC reason). In each point, there are many items, but for time convenience, I will mark down one example that I personally know.
Small companies offer shitty working conditions and pay, but they force you (shitty ones force juniors to do it) to design security architectures, which I did, so I can say I have peeked into the backend a little bit more than the average guy. They don't pay me enough to fix others' bugs or to report them (not like anyone cares).
Basic OPSEC guide for beginners (this is not applicable if you want to hack someone)
incels.is
OWASP top 10:
For detailed explanations, please click into the website.
1. Broken Access Control (BOLA)
An endpoint called GetUsers do not check for user permissions and lack tenant restrictions, making it so everyone can get all data.
2. Security Misconfiguration
The website is configured to show framework version (like ASP.NET 8) if it ran into an error page, so you can scout for the CVEs aka vulnerabilities (publicly available) online for the particular version.
3. Software Supply Chain Failures
A python script uses a honeypot dependency, like "mathlib-1a" but the library is actually malicious and a typo.
4. Cryptographic Failures
A website uses HTTP (instead of HTTPS) to talk to another website, while also sending an insecure Json payload.
5. Injection
EditUser function using a manually assembled string as query to database like $"SELECT {UserInputId} FROM public.users_table...", instead of using frameworks that help you build the query, making it vulnerable to SQL injection like DROP TABLE.
6. Insecure design
A website that has an admin page that does not come with privilege checking, that you can enter by typing in /admin to your browser.
7. Authentication Failures
An API simply requiring the user (via program) to input ID into the endpoint, meaning anyone can call the API with an admin id and be verified as an admin.
8. Software or Data Integrity Failures
An API opening unknown uploaded files without checking them.
9. Security Logging & Alerting Failures
On payment API, the API only logs "a payment was made." Instead of "User Id 123 made a payment of 400$ in July 11, 2026, 4pm"
10. Mishandling of Exceptional Conditions
Printing ex.Message in try catch exception to show the user the stack trace, exposing the details of the app.
As a developer, we study and learn how the most common hacks work in order to prevent them, but for my brocels, who am I kidding? Whether you want to build a hyper-secure incel chatroom, or want to hack some femcel websites, I cannot stop you.
All I am doing is providing what is already widely known, and actively posted by reputable organizations; there are more hacks not listed here, so these are the most common ones.
I will use OWASP Top Ten Web Application Security Risks and provide real case study examples; the legacy (frameworks not updated since 2018) apps in the company I work at exhibit all ten of them, so I know some real examples (I will fictionalize them for OPSEC reason). In each point, there are many items, but for time convenience, I will mark down one example that I personally know.
Small companies offer shitty working conditions and pay, but they force you (shitty ones force juniors to do it) to design security architectures, which I did, so I can say I have peeked into the backend a little bit more than the average guy. They don't pay me enough to fix others' bugs or to report them (not like anyone cares).
Basic OPSEC guide for beginners (this is not applicable if you want to hack someone)
Basic OPSEC tips for dummies
Lots of people in incel spaces get hacked or give their identifies out, so I am gonna offer you some OPSEC tips today. I am a software developer, so I know something about computers, but if you want something more sophisticated, you will have to look elsewhere. I believe the best OPSEC relies...
incels.is
OWASP top 10:
For detailed explanations, please click into the website.
1. Broken Access Control (BOLA)
An endpoint called GetUsers do not check for user permissions and lack tenant restrictions, making it so everyone can get all data.
2. Security Misconfiguration
The website is configured to show framework version (like ASP.NET 8) if it ran into an error page, so you can scout for the CVEs aka vulnerabilities (publicly available) online for the particular version.
3. Software Supply Chain Failures
A python script uses a honeypot dependency, like "mathlib-1a" but the library is actually malicious and a typo.
4. Cryptographic Failures
A website uses HTTP (instead of HTTPS) to talk to another website, while also sending an insecure Json payload.
5. Injection
EditUser function using a manually assembled string as query to database like $"SELECT {UserInputId} FROM public.users_table...", instead of using frameworks that help you build the query, making it vulnerable to SQL injection like DROP TABLE.
6. Insecure design
A website that has an admin page that does not come with privilege checking, that you can enter by typing in /admin to your browser.
7. Authentication Failures
An API simply requiring the user (via program) to input ID into the endpoint, meaning anyone can call the API with an admin id and be verified as an admin.
8. Software or Data Integrity Failures
An API opening unknown uploaded files without checking them.
9. Security Logging & Alerting Failures
On payment API, the API only logs "a payment was made." Instead of "User Id 123 made a payment of 400$ in July 11, 2026, 4pm"
10. Mishandling of Exceptional Conditions
Printing ex.Message in try catch exception to show the user the stack trace, exposing the details of the app.
Last edited:
