News
Server-Timing vs Server Banners for Stack Fingerprints
October 20, 2025
Server-Timing vs Server banners for stack fingerprints is two ways the origin writes its résumé into HTTP. Server and X-Powered-By are explicit product strings. Server-Timing is a performance header (metric name, duration, optional description) meant for RUM and DevTools. On a public marketing response it often names db, graphql, or a route-shaped metric — a quieter inventory than phpinfo, still not a secret. Timing-Allow-Origin is a cousin that lets other origins read those timings. RoastMyOpsec inspects public landing headers for banners. It does not currently score Server-Timing, does not parse metric names into a map, and does not run timing attacks.
The practical difference
A banner is a static boast. Server-Timing is a per-request trace you chose to publish. Client Hints are the other direction: the browser describing itself. CDN fingerprints (cf-ray, via) are yet another layer. Strip banners at the proxy. Keep Server-Timing off public HTML or use generic names with no descriptions.
Authenticated apps may keep detailed timings on a private origin. Do not copy that policy onto the brochure host. See Timing-Allow-Origin vs CORS if you also open timings to other sites.
How to choose what to emit
Public marketing HTML: no Server-Timing, or a single opaque metric if a vendor requires it. APIs behind a dashboard: timings on that host only, still avoid SQL text in descriptions. Edge: strip Server-Timing from cacheable public responses even if the origin added it for debugging.
| Header | Typical leak | Public origin | Takeaway |
|---|---|---|---|
| Server / X-Powered-By | Product and version | Strip | See banners vs fingerprinting |
| Server-Timing named metrics | Backends, routes, durations | Omit or generic names | Not a scored roast F; still hygiene |
| Timing-Allow-Origin * | Other origins can read timings | No on personalized APIs | See TAO vs CORS |
| phpinfo / Actuator | Full runtime dump | No | Different costume, same class |
When Server-Timing still wins
It wins on an internal observability host you authenticate to. It does not win as a substitute for stripping X-Powered-By. Missing Server-Timing on a brochure is healthy.
What the roast can prove
Banner-shaped headers on the HTML response can surface. Server-Timing is not scored. Confirm in DevTools yourself. Pair with verbose API errors if the same request also dumps stacks.
Common mistakes
The first mistake is leaving a debug Server-Timing middleware on the production CDN.
The second mistake is metric names that are the SQL table or GraphQL operation.
The third mistake is treating a roast miss on banners as proof no other fingerprint headers exist.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Is Server-Timing a vulnerability?
- Detailed names and descriptions on a public origin are an information leak. A missing header is fine.
- Should brochure sites send Server-Timing?
- Usually no. Keep RUM on first-party analytics without publishing backend names.
- Does RoastMyOpsec score Server-Timing?
- No. It inspects banners on the landing response. It does not parse timing metrics or run timing attacks.