Basic Threat Detection Every Developer Should Know

Basic Threat Detection Every Developer Should Know

What Is Basic Threat Detection?

Basic threat detection for developers means monitoring application logs for anomalous patterns, implementing rate limiting to throttle automated attacks, and setting alert thresholds that notify your team before an attack causes serious damage. You do not need an enterprise security operations centre — structured logging, Redis-backed rate limiting, and a centralised dashboard are sufficient to establish meaningful baseline security for most applications.

A common misconception in web development is that threat detection requires an expensive enterprise security operations center or an incredibly complex suite of monitoring tools. While those solutions are necessary at significant scale, foundational threat detection relies on a much simpler premise. You cannot protect what you do not observe.

If an attacker attempts to brute-force a login endpoint, or systematically tries to find hidden administration panels on your web application, will your system alert you? Or will the attacker operate silently under the radar?

This post details the practical steps every developer must take to establish baseline visibility into their application's security posture.

Log Analysis and Spotting Anomalies

Your server logs are your primary source of truth. By default, many web frameworks write sparse or unhelpful logs. You need structured logging that captures the critical context of every sensitive request.

Instead of writing simple text strings dynamically to standard output, you should write structured JSON logs. This allows monitoring tools to parse your logs instantly and aggregate the data.

If your backend is returning one hundred 404 Error Not Found responses to a single IP address within an hour, that is not a confused user navigating your site. That is an attacker deploying a vulnerability scanner.

Proactive Rate Limiting

The most effective, immediate countermeasure against automated threats is robust rate limiting. Rate limiting restricts the number of requests a single client can make to your server within a specified time window.

This prevents credential stuffing (where attackers test millions of leaked passwords against your login endpoint) and drastically slows down vulnerability crawlers.

By pushing the state management to Redis, this code ensures that even if you have ten backend servers running simultaneously, the attacker's request count is tracked globally.

Establishing Metric Thresholds and Alerts

It is not feasible to read logs manually all day. You must aggregate your structured logs into an observability platform such as Datadog, Splunk, or an open-source alternative like the ELK stack (Elasticsearch, Logstash, Kibana).

Once your data is flowing into a centralized dashboard, you define static thresholds.

A standard security threshold monitor might look like this: If the sum of Failed Logins across the entire application exceeds 500 within five minutes, trigger a high-priority alert to the engineering on-call channel.

Defending the Perimeter

You have now learned how to structure your logs for visibility, throttle malicious automation through strict rate limiting, and set thresholds to alert your team when the application is under duress.

Detecting threats early is critical, but preventing attackers from reaching your sensitive logic in the first place is even better. In the next post in our web security series, we will transition from basic detection into structural defense, specifically examining how to protect your modern APIs from injection and manipulation.

Advanced Detection Patterns

Once your structured logging and rate limiting are in place, the next layer is correlating events across time and sources. Here are practical patterns that go beyond per-endpoint rate limiting:

Distributed Brute Force Detection

Modern attackers do not hammer one IP address. They distribute credential stuffing attacks across thousands of IPs, staying under per-IP thresholds. To detect this, count failed login attempts per username across all IPs:

This catches distributed attacks that per-IP rate limiting completely misses.

User Agent Anomaly Detection

Legitimate users use real browsers with consistent, well-formed user agent strings. Vulnerability scanners, scrapers, and automated bots often reveal themselves through their user agents. Log and flag suspicious patterns:

When you detect a suspicious user agent, log the full request context and consider returning a 200 OK response with empty data (a tarpit) rather than a 403 — this wastes the scanner's time without revealing that it was detected.

Path Traversal and Injection Attempt Logging

Create a middleware that logs and blocks requests containing common attack signatures:

Integrating with Free Observability Tools

You do not need Datadog or Splunk to get started. These free options give you significant visibility:

Grafana + Loki (Free, Self-Hosted)

Grafana Loki is a log aggregation system designed to work with Grafana dashboards. You push your structured JSON logs to Loki and query them in Grafana. It is lighter than the full ELK stack and free to self-host.

Ship logs from your Node.js application using the winston-loki transport:

Once logs flow into Loki, create a Grafana panel that counts failed_login events per minute and alerts when the count exceeds your threshold.

OpenTelemetry for Distributed Tracing

For applications with multiple services, OpenTelemetry is the open standard for tracing requests across services. Distributed tracing reveals attack patterns that span multiple microservices — an attacker probing your auth service, then your user service, then your payment service in sequence.

Building a Security Incident Response Checklist

When your alerts fire, you need a clear, practised response process. Without one, you waste critical minutes during an active attack:

1. Preserve evidence first: Take a log snapshot before making any changes. Logs may be overwritten.
2. Identify the scope: How many IPs are involved? Which endpoints are being targeted? How long has it been happening?
3. Apply targeted blocks: Block specific IPs or IP ranges at your load balancer or WAF — not in application code where it costs resources to evaluate.
4. Rotate exposed credentials: If any secrets may have been accessed, rotate them immediately.
5. Document the timeline: Record what happened, when you detected it, what you did, and the outcome. This is required for any compliance audit.
6. Post-mortem: After the incident, identify the detection gap. How long was the attacker active before detection? What would have caught it earlier?

Summary and Next Steps

You have now built the foundation of a proactive security posture:

• Structured logging captures the context needed to identify attackers from your logs.
• Rate limiting with Redis stops automated attacks before they succeed.
• Distributed brute force detection catches attacks that per-IP limits miss.
• Alert thresholds ensure your team is notified before damage occurs.
• Observability tooling (Grafana/Loki or ELK) gives you a centralised view across all services.

For the next layer of protection — securing your APIs against injection, authentication bypass, and privilege escalation — see How to Protect APIs from Attacks and How to Secure Web Apps. For phishing and social engineering defence, see How to Avoid Online Phishing Attacks.

External Resources

• OWASP Top 10 — the industry-standard list of the most critical web application security risks, updated regularly.
• Grafana Loki documentation — set up free, self-hosted log aggregation.
• OpenTelemetry getting started guide — add distributed tracing to your application.