[kdbg]

You can, but maybe not in the "standard" way.

Standard way being trying to measure the precise differences between requests. The smaller the difference the more requests are needed to level things out and that just becomes pretty impractical quickly but still possible in some situations.

If you actually wanted to do a timing attack on the web you'd probably want to do something like a "Timeless Timing Attack" [0]. At a high-level the idea is to measure relative timing differences rather than the precise difference. Answering which request completes faster rather than how much faster.

The specific attack from the paper is taking advantage of HTTP/2 multiplexing to send two requests within a single packet, ensuring they arrive at the same time. Then uses the response order to determine which was processed faster/slower. It still requires making multiple requests to smooth out the data just not as much since you're only interested in the relative competition time.

Its not practical everywhere, but its more practical for the web than the traditional technique.

[1] https://www.usenix.org/conference/usenixsecurity20/presentat...