In the last few days, we analyzed real server access logs from a live application. What we found is something every developer should understand:

👉 Your application is being scanned and attacked — constantly.

Not by a single attacker, but by automated bots crawling the internet looking for vulnerabilities.

This blog breaks down:

  • What kinds of attacks are happening
  • Real examples from logs
  • What developers should do to secure their systems

🔍 What We Observed

From the logs, multiple suspicious request patterns appeared:

1. 🔥 Remote Code Execution (RCE) Attempts

Example:

/hello.world?%ADd+allow_url_include=1+%ADd+auto_prepend_file=php://input

 

👉 This is a classic attempt to execute malicious PHP code remotely.

2. ⚠️ PHPUnit Exploit Scanning

Examples:

/wp-content/plugins/.../phpunit/phpunit/src/Util/PHP/eval-stdin.php

 

👉 Attackers are trying to exploit old PHPUnit vulnerabilities.

📌 Important:
Even if you DON'T use WordPress — they still try.

3. 📡 Microsoft / Exchange / Autodiscover Probing

Examples:

/autodiscover/autodiscover.json?@zdi/Powershell
/ecp/Current/exporttool/microsoft.exchange.ediscovery.exporttool.application

 

👉 Bots assume your server might be running Exchange and try known exploits.

4. 🧪 Random Endpoint Scanning

Examples:

/aab9
/aaa9
/html/ie.html
/SDK/webLanguage

 

👉 These are blind scans to find hidden endpoints or misconfigured apps.

5. 🔐 API Abuse Attempts

Examples:

/iams/api/v1/forgot-password/sendOtp
/iams/api/v1/slots/reserveSlot

 

👉 Attackers test APIs for:

  • Rate limit issues
  • OTP abuse
  • Business logic flaws

6. 🧨 XSS / Injection Payloads

Example (encoded attack):

/%27%22 class="error__button...

 

👉 This is an attempt to inject HTML/JS into your frontend.

🧠 Important Insight

👉 These attacks are automated.
👉 They don't care what tech stack you use.
👉 If your server is public, it WILL be scanned.

🛡️ What Developers Should Do (Practical Defense)

1. 🚫 Disable Unused Entry Points

If you are not using:

  • /wp-content
  • /phpunit
  • /vendor

👉 Block them at Nginx level:

 

location ~* /(vendor|phpunit|wp-content) {
    deny all;
    return 404;
}

 

2. 🔒 Protect Against RCE

Never allow:

  • allow_url_include
  • dynamic file execution

👉 In PHP:

 

allow_url_include = Off
allow_url_fopen = Off

 

👉 In Django:

  • Never use eval()
  • Avoid unsafe exec()

3. 🧱 Web Application Firewall (WAF)

Use:

  • Cloudflare / AWS WAF
  • ModSecurity

👉 Blocks:

  • SQL Injection
  • XSS
  • Known exploit patterns

4. 🚦 Rate Limiting (Very Important for APIs)

Example (Django):

 

from rest_framework.throttling import UserRateThrottle

 

👉 Protect endpoints like:

  • OTP
  • Login
  • Payment APIs

5. 🔍 Input Validation Everywhere

Never trust user input.

✔ Validate:

  • Query params
  • Headers
  • JSON body

✔ Use:

  • Django serializers
  • Laravel validation rules

6. 📉 Hide Server Information

Remove headers like:

  • Server
  • X-Powered-By

👉 In Nginx:

 

server_tokens off;

 

7. 🚫 Custom 404 & Error Handling

Default error pages leak info.

👉 Always use custom responses:

  • Generic message
  • No stack trace

8. 🔑 Secure Sensitive Endpoints

For APIs like:

/forgot-password
/reserveSlot

 

👉 Add:

  • CAPTCHA
  • OTP cooldown
  • IP-based throttling

9. 📊 Monitor Logs Continuously

Logs are your best defense.

Track:

  • Repeated 404s
  • Suspicious paths
  • High-frequency hits

👉 Integrate:

  • Fail2Ban
  • ELK Stack
  • Custom dashboards

10. 🚨 Block Bots Automatically

Use Fail2Ban or scripts:

👉 Example logic:

  • 10 suspicious hits → block IP

⚡ Final Takeaway

👉 Security is NOT optional
👉 Attackers don’t target YOU — they target EVERYONE
👉 Your job as a developer is to reduce attack surface