Top-5 stupid security mistakes in web apps

by Ivan Novikov

Image by Byseyhanla (Own work) [CC BY-SA 4.0, article re-posted from https://medium.com/@d0znpp/top-5-stupid-security-mistakes-in-web-apps-2f26f52ebfaa

In this blog entry, I will summarize some commonly overlooked issues which have been affecting many web projects for the last 5 years. All of them are obvious and super predictable and could be used be script kiddies as well as by fully automated scanners and internal security checks. Let’s go!

  1. Apache to Nginx migration configuration files disclosure. Just don’t forget that .htaccess and .htpasswd files are not usable by Nginx. Therefore it’s possible to retrieve their content by HTTP request like this: https://i-moved-from-apache-to-nginx.com/.htpasswd
  2. CDN implementation source code disclosure. The easiest way to start using the CDN is to copy all the files from the web server to a CDN. In this case, you shouldn’t forget that CDNs are essentially static content servers and all the application code there will be accessible as well as images and other resources, like this: https://i-started-to-use-CDN.com/index.php
  3. Host-based authentication bypass by using X-Forwarded-For, X-Real-IP and other headers. Don’t forget that all the headers in HTTP requests are belong to attackers. If you would like to check the source of a request for belonging to intranet or localhost, double check what you are using as a source. This simple curl command can help: curl -X ‘X-Forwarded-For: 127.0.0.1’ https://i-protected-by-host-based-auth.com/
  4. Virtual hosts abusing. I mentioned before, all the HTTP requests are belong to attackers, therefore it’s impossible to trust in anything inside it. And the HOST header is not an exception. If you have a staging.company.com virtual host available at your load balancer side, believe me, even if you don’t have a CNAME record in your DNS configuration, an attacker will find and exploit this host. This simple command can help to identify this issue: curl -X ‘HOST: staging.intranet’ https://i-like-virt-hosts/
  5. Cross Site Scripting by insecure crossdomain.xml. A lot of web projects still have issues in this configuration file. This allows an attacker to operate with vulnerable resources by using a victim’s session, the same as with XSS vulnerabilities. Please double check all your crossdomain.xml files for the wildcard domains like this:
<allow-access-from domain="*" secure="false" />
<allow-access-from domain="youtube.*" secure="false" />

These Top 5 mistakes list is simply my own list based on the statistics collected by Wallarm over the last 5 years. I hope it was a useful read and don’t forget to automate all these checks because security means continuous defense. Enjoy!

Recent Posts

The CISO’s Dilemma: How To Scale AI Securely

Your board wants AI. Your developers are building with it. Your budget committee is asking…

4 days ago

Agent-to-Agent Attacks Are Coming: What API Security Teaches Us About Securing AI Systems

AI systems are no longer just isolated models responding to human prompts.  In modern production…

5 days ago

Everyone Knows About Broken Authorization – So Why Does It Still Work for Attackers?

Broken authorization is one of the most widely known API vulnerabilities.  It features in the…

2 weeks ago

From Shadow APIs to Shadow AI: How the API Threat Model Is Expanding Faster Than Most Defenses

The shadow technology problem is getting worse.  Over the past few years, organizations have scaled…

4 weeks ago

Inside Modern API Attacks: What We Learn from the 2026 API ThreatStats Report

API security has been a growing concern for years. However, while it was always seen…

4 weeks ago

CISO Spotlight: Craig Riddell on Curiosity, Translation, and Why API Security is the New Business Imperative

It’s an unusually cold winter morning in Houston, and Craig Riddell is settling into his…

1 month ago