Closed bradchoate closed 4 years ago
Hey! Thanks for the report.
I'm not clear on how an access key would help here. This endpoint is called from the client for standard Prebid.js
video bidding... so it seems like a malicious user could just use dev tools to scrape the API key from the request of a legitimate page.
I'm definitely not a security expert, though... so I might be missing something?
I’m not familiar with the Prebid.js use case. We are considering running a prebid-server/prebid-cache stack to serve Header bidding for AMP pages where Prebid.js isn’t used. In this case; prebid-server populates the cache and could use an API key that wouldn’t be exposed to the public.
ahh, yes. That makes total sense for setups which only support AMP/Mobile.
If you wanted to make a PR which adds auth to the endpoint, we'd definitely review it. It'd have to be something you can enable or disable through the app config, though.
From a quick review of the Prebid server adapter of Prebid.js, it appears to just use the GET service request as well. Public read without an API key is fine; public write isn’t.
It uses both. See:
This occurs even if PBS isn't involved at all.
I'm going to close this issue. PRs to add configurable access controls are welcomed. Our use cases haven't warranted it, so we haven't built it, but someone else certainly can.
I understand that the GET method for prebid-cache should be publicly accessible, but there's no reason that the POST method should be public. Some mechanism to secure the POST method needs to be added to prevent abuse.
Currently, anyone can write to the Appnexus prebid-cache instance, since it doesn't require any kind of access key to POST:
Expected result: a 400 error (Invalid request), since it should require an API key of some kind to be in the request.
Actual result: a 200 response, including the uuids issued for each element stored to the cache.