See use case #9 for a description of this requirement.
There are two types of beacon abuse you may need to protect against:
There's nothing you can do in javascript to prevent denial of service attacks, but you can configure your server to rate limit beacons originating from a single IP. You typically shouldn't be receiving beacons faster than a user can open websites. You'll also want to do some operating system/web server level configurations to detect abusive access patterns. The majority of these are beyond the scope of this document, but we have a few tips on building your beaconing back end to protect you from an attack.
Most developers will create a back end script that they use as the beacon_url parameter
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 most common reason for this kind of abuse is that someone really liked your page design and copied it to their own server, including the boomerang javascript, only they didn't update the beacon_url, so it still beacons to your server. You probably don't want this.
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
crumb.
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
using the 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.
The nonce also doesn't protect you from someone pulling the beacon out of your page — with a valid nonce, then modifying the beacon parameters and sending it off to your server. Protecting against this requires you to sign the parameters in the beacon, but this isn't something that you can do in javascript. I do not know of a general purpose solution to this problem.
The latest code and docs is available on github.com/SOASTA/boomerang