Would anyone notice an attack on your customer portal?

The login screen can be doing its job while the rest of the organization sleeps through the interesting part. An incorrect-password message is useful to the visitor. A reliable security signal needs to travel a little farther.

A customer login can reject an unwanted request perfectly while leaving the business unaware that anything happened. The useful test follows the event all the way to a responsible person.

Most portals can display “Incorrect password.” But who knows if it happens hundreds of times across dozens of accounts at night?

Rejecting a login is an application decision. Detecting suspicious activity requires an operational chain that can fail at several points.

Follow the signal, not the configuration

Asking whether logging, a web application firewall, and alarms are enabled is useful. It does not establish that an event reaches someone able to act.

The path to verify is authentication decision → structured event → collection → detection → notification → acknowledgment. Each transition can fail. A rejected request proves little about logging; a log proves little about detection; an alarm proves little about human receipt.

OWASP's logging guidance explains why application security events need attention beyond ordinary web-server access logs. For a portal review, that means looking at the application's authentication decisions and the route by which useful events reach analysis and response. [1]

What a useful login event contains

A structured event should identify the time, account identifier (or synthetic identity in a test), authentication decision, source, and request identifier used to correlate telemetry.

An event such as auth.login.failed with a timestamp and correlation ID beats “Login error.” It should not contain the entered password, session cookie, access token, or unnecessary personal information.

Attackers can generate log volume cheaply. Routing every edge rejection through PHP, a database, and several verbose processors amplifies the cost. Block obvious unwanted traffic upstream where appropriate; preserve high-value application security events; establish explicit retention; and monitor the logging pipeline itself for dropped events or saturation.

Logging is useful only when it stays available, trustworthy, and affordable during an incident.

The firewall sees traffic. The application sees accounts.

A web application firewall can rate-limit requests, challenge clients, and evaluate patterns beyond a single IP address. AWS WAF, for example, supports different request aggregation criteria for rate-based rules. They need traffic-specific tuning. [2]

But a firewall at the edge may not know whether 50 requests from changing addresses all targeted the same customer account. Conversely, one request against each of hundreds of accounts may be significant to the application even if no individual source looks extreme.

Correlate edge behavior with account-level outcomes: bursts against one account, unusual failures across many accounts, and other business-relevant patterns. Test those detection rules against ordinary behaviors—mistyped passwords, password-manager retries, or a legitimate surge after a service interruption—before aggressive blocking is introduced.

A controlled test reveals the missing link

Consider a hypothetical demonstration in an isolated development environment, using only a synthetic account and test data. The operator makes a small, predetermined number of incorrect login attempts. The team then follows each event across the application, log collector, detector, and notification destination.

Pass criteria: expected events are recorded, the rule fires once, a named recipient acknowledges the notification, and one mistake followed by a successful login generates no alert.

Record event-to-detection, detection-to-notification, and notification-to-acknowledgment delays. A red dashboard is only part of the story.

The test should also separate two claims often confused in cloud monitoring: a synthetic alarm-state change can verify downstream notification routing, while only an application-generated event flowing through the detector verifies the complete detection path. Both checks are useful; they prove different things.

Five questions worth taking to your next review

• Can the application produce structured success and failure events without logging credentials or tokens?
• Can the organization trace a synthetic event through collection and detection using consistent timestamps or correlation identifiers?
• Who receives the resulting alert, and what happens if that person is unavailable?
• What is the observed detection-to-notification time, and how often do legitimate actions trigger the same rule?
• After a missing control is repaired, can the entire test be repeated and its result retained as evidence?

Before testing, define environment, identities, limits, stop conditions, evidence handling, and recovery. Public systems and client environments are not suitable targets for an unapproved demonstration.

Make the control provable

A useful finding states: This synthetic event matched this rule, reached this recipient, and was acknowledged within this measured time. If the chain fails, identify the break and retest after repair.

Business-critical portals deserve controls that can be demonstrated, not simply enabled. If your team cannot explain what happens between an attempted login and a human response, that is a useful place to begin.