
When we successfully deployed our project to AWS, it felt like a major milestone. However, that excitement was quickly tempered when I discovered some suspicious access records in the Nginx logs, that was completely beyond our expectations.
"GET /config/.htpasswd HTTP/1.1" 403 180 "-" "-"
"GET /wp-login.php HTTP/1.1" 200 3120 "-" "-"
What happens
After noticing those suspicious entries in our Nginx logs, I started digging deeper. The requests like GET /wp-login.php and GET /config/.htpasswd were clear signs of automated bots or malicious users scanning for vulnerabilities. These attackers weren’t targeting us specifically, they were casting a wide net, looking for known weaknesses in websites.
Hackers often use automated scripts to crawl the web, searching for unprotected admin panels, outdated software, misconfigured permissions, or exposed files. If they find a weak spot, they can exploit it to gain unauthorized access, steal data, install malware, or even hijack the entire server.
In our case, even though our app isn’t based on CMS, bots were still trying common attack vectors just in case we had overlooked something. It was a wake up call: deploying a project publicly on the internet means it’s instantly exposed to threats—no matter how small or obscure the project is.
How to protect website and infrastures
To defend against these kinds of attacks, it’s essential to have multiple layers of protection. Here are some key practices:
- Keep software updated – Whether it’s the OS, frameworks, or dependencies, outdated code is often a target.
- Limit access – Restricting access to sensitive endpoints and using strong authentication methods can prevent unauthorized use.
- Monitor logs – Regularly reviewing logs helps identify suspicious patterns early.
- Use HTTPS – Encrypting traffic ensures that data is not intercepted in transit.
- Implement firewalls and rate limiting – Blocking abusive IPs and limiting requests helps protect against brute-force and denial-of-service attacks.
However, managing all this manually can be overwhelming. That’s where Cloudflare comes in—a platform that handles around 20% of the entire internet’s traffic and offers robust security tools for websites.
How Cloudflare works
We onboarded Cloudflare to our project to gain an additional layer of defense.

Here’s how it helps:
- DNS and Anycast Network: When we updated our domain’s nameservers to point to Cloudflare, it began acting as a reverse proxy. With its Anycast network, traffic is routed to the nearest data center, improving speed and resilience.
- Traffic Proxying: Cloudflare sits between users and our AWS server, filtering out malicious requests before they reach us.
- DDoS Protection: Distributed Denial of Service attacks attempt to overwhelm a site with traffic. Cloudflare absorbs and mitigates these floods without downtime.
- Web Application Firewall (WAF): Their WAF automatically blocks known attack patterns and vulnerabilities, such as SQL injections and XSS attacks.
- Bot Management: Using machine learning, Cloudflare can differentiate between human and bot traffic, blocking bad bots while letting legitimate traffic through.
After enabling Cloudflare, we immediately saw a drop in malicious requests hitting our server. Most of the junk traffic was filtered out at the edge, never even touching our infrastructure.
Some findings and thoughts
- Even small or student led projects can attract unwanted attention as soon as they are publicly accessible.
- Security should not be treated as an afterthought. It needs to be integrated into every stage of the development lifecycle.