ASM false positives before a marketing launch
A financial services firm exposes a customer portal through BIG-IP ASM in blocking mode. The portal serves 650 requests per second at peak, uses JSON APIs for account lookup, and has a file-upload endpoint for PDF statements. After a policy update, legitimate users searching for terms such as 'drop table' and 'union' receive request-blocked pages, and the upload endpoint rejects filenames containing spaces. The security team wants to keep blocking enabled and avoid disabling signatures broadly. The application team wants a fix before Monday's marketing launch. The ASM policy is currently enforced with staging disabled, and the team has not reviewed learning suggestions for two weeks. The portal is also seeing automated credential-stuffing attempts against the login API, which the business wants to slow down without blocking partner integrations that call the same API.
1. How would you resolve the search-term false positives while keeping the policy in blocking mode? Be specific about ASM features and the order of operations.
Read the worked answer
Do not disable the SQL-injection signatures globally. First enable staging and let the policy learn while still enforcing the existing blocking policy, then reproduce the search requests and identify the exact violations: which parameter, which signature, and whether the parameter reaches a SQL interpreter. If the search parameter is not used in a SQL query and is safely encoded, add a narrow parameter exception or disable the specific signature only for that parameter and URL. Accept the corresponding learning suggestions only after reviewing them, then return the policy to full enforcement.
Keep the blocking mode on throughout; staging is a learning state, not a reason to become transparent. Test with the exact search strings, including encoded variants, and confirm that genuine SQL injection attempts against other parameters are still blocked. Record the exception, its owner, and an expiry date so it does not become permanent.
Because the team has not reviewed suggestions for two weeks, do not bulk-accept them. Review by URL and parameter, and reject suggestions that would weaken authentication or upload protections.
2. What would you change for the PDF upload endpoint so legitimate statements pass without opening a general file-upload hole?
Read the worked answer
Treat the upload endpoint as its own security zone rather than weakening global file-upload settings. Create a separate URL or, if the application architecture supports it, a separate ASM policy for the upload path. Allow only the PDF file type, enforce a maximum file size, and validate the declared content type against the actual file content where possible. Keep executable and script extensions disallowed, and do not allow double extensions or path traversal in the filename.
The spaces in filenames are a filename-validation false positive, not a reason to disable all filename checks. Adjust the specific filename rule or add a narrow exception for spaces on that URL while keeping checks for traversal, null bytes, and dangerous extensions. If ASM cannot inspect PDF content deeply, pair it with an external malware scanner and log the upload metadata.
After the change, test legitimate PDFs with spaces, long names, and non-ASCII characters, plus malicious PDFs and renamed executables. Keep blocking enabled and monitor violations for the upload URL during the launch.
3. How do you address credential stuffing without blocking partner API integrations that call the same API?
Read the worked answer
Separate the human login flow from partner API traffic. If partners authenticate with mutual TLS, API keys, or OAuth client credentials, give them a distinct virtual server or URL path and a distinct ASM policy. Apply credential-stuffing controls to the human login endpoint: login enforcement, brute-force protection, rate limiting, and device or bot signals. Do not disable bot defense globally just because partners share the same backend.
For partners, keep authentication and rate limits but tune thresholds to their expected call volume, and monitor for anomalous patterns rather than blocking the integration outright. Use ASM logs and analytics to distinguish a partner's steady traffic from a burst of failed logins from many source addresses.
The marketing launch raises the stakes: stage the login policy changes, test with real partner traffic, and have a rollback plan. Blocking a partner integration during launch can be more damaging than the credential-stuffing attempts, so measure before enforcing new thresholds.