Be consistent about HTTP status in aggregator API on failures

Glenda Leonard at Mozilla reported that traffic to the aggregator API that didn't appear to originate from Divvi Up's divviup-api. That's to be expected: a listener on the internet will get portscanned and subjected to automated attacks. However these requests apparently yield a variety of HTTP statuses: "they are 302, 400, 401, 404 and 502. with 404 being the highest."

My expectation would be that unauthenticated requests should get uniform responses regardless of the request path or body, to avoid leaking information to attackers. Always 401 Unauthorized is probably fine. I'm also concerned about 502s.

Unfortunately we don't have great information on exactly what routes were being accessed (though apparently they're all GET requests). Still, we should be able to write some tests and do some code audits.

Start by locating the aggregator API's authentication and error-handling entry points, then audit the GET request paths and existing tests relevant to unauthenticated traffic. Done means the relevant request cases are covered by tests and their HTTP failure behavior is consistent, with unexpected 502 responses addressed.