When your authorization layer correctly returns 403 for unauthorized function calls, those 403s are valuable signal: someone is testing which functions they can reach. A user who receives 10+ 403 responses in a short window is systematically probing your API for unprotected endpoints.
Log every 403 response with context: user ID, IP address, endpoint path, HTTP method, timestamp. Alert the security team when a single user or IP generates an unusual volume of 403 responses within a time window (e.g., more than 20 in 5 minutes).
Attackers probing for BFLA typically start from known user endpoints and systematically vary paths and methods. Each attempt that returns a 403 tells them “this function is protected.” Each that returns 200 is a hit. If you monitor 403 volume per user, you can detect the probing behavior before the attacker finds a 200.
When 403 spikes are detected: temporarily block the user or IP from calling admin-path patterns, require re-authentication, or trigger a CAPTCHA. Log the full list of paths they tried — this is your inventory of what an attacker considers potentially unprotected. Use it to audit those endpoints specifically.
Put function-level permissions on your security review calendar. Permissions tend to expand as new roles and features are added and rarely shrink without a deliberate, scheduled review.