See use case #9 for a description of this requirement.
There are two types of beacon abuse you may need to protect against:
Most developers will create a back end script that they use as the
of boomerang. The problem here is that since these requests cannot be cached, this script will run
on every beacon request, and will consume web server resources, and probably database resources on
every request. During a denial of service attack, this can bring your servers down.
A better way to handle it is to have a lightweight web server running on your beaconing server, and
have this server configured to only respond to requests for the beacon URL. It should send back a
HTTP 204 response to all beacon requests. This is easy enough to configure within the
server and means that it doesn't have to do a disk lookup for any request. The server will still
write the request to its access logs, and this should include all query string parameters and cookies.
Periodically - say once an hour or once a day (depending on the volume of beacons), you can batch process your logs and figure out your actual beacon parameters from there, discarding any obviously fake or abusive beacons. The actual code to extract data from a beacon is the same regardless of whether you do it on every request or as a batch. See Howto #0 for more information on extracting data from a beacon.
There's much more information online about DoS attacks and how to protect yourself from them.
The easiest way to fix this is to just check the referrer of all requests and block any that don't come from your own domain. This works for the clueless abuser case, but not for the intentional abuser.
The intentional abuser is someone who will try to exploit all URLs to your site just to see if they
can get something out of it. What they try isn't really important. There's only one legitimate way
of using your beacon, and you should block all other uses. The best way to do this is through a
nonce or a
This is a string that is valid for one use only. It probably includes the current timestamp and a
validity period as part of its hash. You generate it on every page requests and add it to boomerang
BOOMR.addVar() method. On your beacon server, you then validate the nonce
before accepting the beacon. If you're batch processing, you'd use the timestamp of the request and
not the time that you're running the batch job in order to validate the nonce.
BOOMR.addVar("nonce", "125a7b79de989876cce970f0768a07"); // your nonce will be different
While the nonce can protect you from someone hitting your beacon URL directly, it does mean that your main page cannot be cached, since the nonce will change on every request.