Tips to prevent Ddos attacks and hacker attacks without the use of javascript?

I'm developing an application that doesn't store ip addresses. But it doesn't mean that it's not protected. I used policies, middleware, requests, route protection. But I feel that by not saving IP addresses, and not using JS, the logs are weakened. Could you give me a tip on how to deal with this?

Without JS and IP logs, your best defense is rate limiting at the server level. Use Nginx or HAProxy to limit requests per second per session. Add a proof-of-work challenge before serving content, like a hashcash-style puzzle that the client must solve. Captcha alternative: use a simple math question or text-based challenge. Also, consider using TOR's built-in rate limiting through Torrc configuration.

[removed]

Ok. - - Would it be nice after a while of logging in, to require a click for continued browsing, such as a "click here to prove you are not absent" to continue? Still, don't let totally new users not do so many actions in 5 minutes? not disrupt the user experience.

- Also, a CDN in front, to filter well.? which one would be good? Not Cloudflare

Actually, Hashcash requires JavaScript to solve, so that won't work for a No-JS app. Math captchas are also easily bypassed by AI. Since you aren't logging IPs, you can't do user-specific rate limiting in your application code. The only viable solution is to enforce connection limits or SSL session-based rate limiting at the infrastructure level (Nginx/HAProxy) before requests even reach your app. Trying to handle this in the application layer without identifiers is impossible.

The 'click to continue' idea is solid, it's an interactive challenge that works without JS (just a simple form POST) and effectively stops automated bots while keeping real users safe. However, be careful with 'limits for new users'; attackers will just rotate IPs to bypass this, while it frustrates legitimate new users.

For a CDN that respects privacy (no IP logging) and isn't Cloudflare:

Self-hosted Reverse Proxy: Use Nginx, HAProxy, or Caddy on your own infrastructure or a VPI. This gives you full control over rate limiting and logging policies.

Privacy-Focused CDNs: Look into ArvanCloud (check their privacy policy carefully) or StackPath (though they log for security, they are less data-harassing than others).

Tor Hidden Services: If your audience uses Tor, consider offering an onion service which inherently protects user IPs.

Avoid mainstream CDNs if your goal is zero IP logging, as most comply with data retention laws that require logging. The safest bet is always your own infrastructure.

MR3C0, So, could a CDN help with that? Using fail2ban requires the attacker's IP address to ban them. Also, within the application, ratelimiting must be used.

You're right: fail2ban is impossible without IPs. A CDN can help by filtering traffic before it hits your server, but the CDN provider will see the IP (even if you don't log it). If you want zero entities to ever see the IP, you must restrict access to authenticated users only and rate limit by Account ID. For anonymous users, some entity (CDN or Proxy) must see the IP to filter abuse; there is no magic way to stop bots without an identifier.

Good ideas. For the "click to prove you're human" approach, implement it as a time-based challenge, not a request-based one. After 15-20 minutes of browsing, show a simple interaction gate. This catches bots that leave tabs open while not annoying real users. For new users, keep a grace period of 5-10 minutes with no limits.

For CDN without Cloudflare, look at BunnyCDN or KeyCDN. They're privacy-respecting and don't require JavaScript. But for a hidden service, don't use a CDN at all. Use a reverse proxy like Caddy or Nginx on a separate server, then connect it to your backend through an internal TOR circuit. This keeps your infrastructure hidden while still giving you caching and filtering.

Solid points. You're right about Hashcash needing JS. What I was thinking was a server-side proof-of-work where the server sends a challenge, the client computes it manually or via a script, and sends back the answer. But that does add friction.

For rate limiting without IPs, you can use SSL session IDs or TOR circuit IDs at the Nginx level. Nginx can rate limit based on these without touching your application. It's not perfect, but it's the best option without JavaScript.

If you have experience with HAProxy for hidden services, I'd be interested in hearing your setup. Always looking to learn from people who've built this stuff in production.