We’ve been integrating Veracode dynamic scanning into our CI/CD pipeline for about six months, primarily scanning a set of Spring Boot microservices that expose REST APIs. The pipeline itself is built with Airflow, triggering scans upon deployment to a dedicated staging environment. While the scan coverage for unauthenticated endpoints has been satisfactory, we are consistently observing that endpoints behind authentication—specifically JWT-based token authentication—are being missed entirely by the dynamic scan.
Our configuration process for the scan follows the documented procedure for authenticated scanning. We have configured a “login script” using the Selenium-based method provided by Veracode, which successfully logs in and retrieves a bearer token. This token is then, to our understanding, supposed to be used for subsequent authenticated requests. The script execution log confirms a successful login and token capture. However, the scan report shows zero issues and, more tellingly, zero coverage for any of our authenticated routes (e.g., `/api/v1/users`, `/api/v1/transactions`). Only the public `/login` and `/health` endpoints appear in the results.
This leads me to suspect a fundamental misconfiguration in how the authentication context is being passed to the crawling and testing engine. I am outlining our current setup below for scrutiny.
**Current Authentication Script (Simplified):**
```javascript
var selenium = require('selenium-webdriver');
var By = selenium.By;
var until = selenium.until;
async function login() {
var driver = new selenium.Builder().forBrowser('chrome').build();
try {
await driver.get('https://our-staging-env/login');
await driver.findElement(By.name('username')).sendKeys('${username}');
await driver.findElement(By.name('password')).sendKeys('${password}');
await driver.findElement(By.css('button[type="submit"]')).click();
await driver.wait(until.urlContains('dashboard'), 10000);
// Script is configured to extract token from localStorage
var token = await driver.executeScript('return window.localStorage.getItem("authToken");');
return {
auth_headers: {
"Authorization": "Bearer " + token
}
};
} finally {
await driver.quit();
}
}
login();
```
**Key Configuration Points in Veracode Platform:**
* **Scan Type:** Dynamic Analysis with Authenticated Scanning enabled.
* **Authentication Method:** Login Script (as above).
* **Starting URL:** Our staging application root.
* **Crawl & Audit Settings:** Default "Fast" crawl, with any additional seed URLs for authenticated areas included.
The disparity between the script’s success and the scan’s actual coverage suggests the authentication context may not be propagating correctly. I have several hypotheses, but lack definitive evidence from the platform’s logs:
1. Is the `auth_headers` object returned by the script correctly applied to *all* subsequent HTTP requests made by the crawler, or only to requests originating from the same session as the login script?
2. Could the issue be related to the Selenium driver quitting (`driver.quit()`) at the end of the script, thereby terminating the session that the crawler might be relying on?
3. Does Veracode’s dynamic scan engine respect and forward authentication headers when it discovers new URLs via links or form actions that point to our authenticated API endpoints, which are typically not linked via HTML but rather consumed by a front-end application?
We are considering workarounds, such as temporarily disabling authentication on the staging environment for scans, but this defeats the purpose of testing the authenticated logic. Has anyone successfully configured Veracode dynamic scanning for a modern SPA-backed API (like Spring Boot + React) where the API endpoints are protected by a token stored client-side? Any insight into the precise mechanism by which the login script’s output binds to the crawling phase would be invaluable.
Extract, transform, trust
Check if your Selenium script actually stores the token in the correct Veracode session variable. The login can succeed but the token might not be attached to the scan's HTTP client.
The scanner won't just infer your authenticated route structure. You need to explicitly seed it. Provide a detailed site map or a simple crawl script that hits your authenticated endpoints first, using the captured token, before the main scan kicks off.
Also, JWT expiry could be cutting the scan short. Your staging tokens might have a short TTL.
Least privilege is not a suggestion.
Yep, that "zero coverage" report is the classic tell. The scanner likely never gets the auth token attached to its crawler phase.
Two things I'd bet a coffee on:
* Your Selenium script logs in and captures the token, but that's only for the *login verification*. The separate scan engine that does the actual crawling and attacking might be using a different, empty session. You need to explicitly pass the auth cookie or header into the scan setup, not just the login script.
* Have you checked the raw HTTP traffic logs from the scan? The scanner usually dumps these. I'd grep for your authenticated endpoints - my guess is you'll see 401s for every single one. The token might be sitting in a variable doing absolutely nothing 😅