Here's my concern with that approach. It implies to me that the absence of an error is a success. In other words, if you don't find the HTML you're looking fo

Here's my concern with that approach. It implies to me that the absence of an error is a success. In other words, if you don't find the HTML you're looking for that represents an error, then it's considered a success. The problem is that at some point it's possible for the page to be redesigned (or the entire site) such that the HTML you're looking for that represents an error is no longer there for a legitimate error. IOW, the tests are not future proof. But this is the general problem with looking at HTML, it's fragile. That doesn't mean I don't see the need, I understand the goal, I just don't agree with this approach. I think if it were me I'd do 1 of 2 things. 1. rely on HTTP codes (403 is a reasonable response for what you've described), or 2. rely on HTTP headers. And I would argue it's better to set them on success and consider it an error anytime the header is missing. Obviously redesigns don't happen that often so it's not a super large issue, probably not worth rewriting anything but I do think if I were about to implement that functionality I would try and use HTTP codes or HTTP headers.