UPDATE:
There was previously an error in this tutorial. It was claimed that a code such as

if ((_root._url.indexOf("http://www.flashcomguru.com") == 0) || (_root._url.indexOf("http://flashcomguru.com") == 0) ){
gotoAndStop("niceone");
} else {
gotoAndStop("feckoff");
}

inside your swf would solve the problem of succeeded connections when someone linked directly to the swf. Unfortunately this does not seem to be the case. It is however a workable solution if the swf has been 'stolen' is being served from another domain. However the server side method already takes care of this...
This leaves quite a big hole in the security of FCS!


The following tips should be read in conjuction with my tutorial on securing your application with the help of a server side script. It uses the client.referrer property to authenticate the connecting domain (the domain the swf is originating from).

More than one way to Rome
So far we have seen different ways by which (in particular some italian) sites have tried to hijack flashcom applications, stealing bandwidth and connections. One way was to spy on the connection string by hacking the swf file and using this to connect straight to the FCS Server. This approach only works if the server is completey unsecured meaning the owner hasn't made use of the security features in vhost.xml nor has the owner used any sort of client.referrer check. Here is an image of how your server.xml should not look:

Instead you should use <Allow>yourdomain.com</Allow>. This will offer a bit of protection.

Still not enough
However I think we all were surprised to find out that by simply embedding a swf from another domain into an HTML page we could steal the application, even with all the above measure in place. Not good.

If a hijacker was to put the swf on his own server an run it then it wouldn't connect. However if the thief would simply embed the swf like so
value="http://www.yourdomain.com/yourfile.swf" into his own page then the client.referrer would resolve to 'yourdomain.com' and the connection would succeed. Obviously the server.xml method also relies on the referrer that the swf file sends, not the HTML file in which it is embedded...

You will find that if you try and run it locally or on another domain then the (pretended) connection will fail.
We are working on a method that will stop people from linking to the swf on your server.

Taking things a step further
If your webserver is Apache then why not use .htaccess, courtesy of Fernando:


That's pretty much bullet proof. Check out the complete article by Fernando. It also features some steps you can take against people trying to frame your site.

Further info on the topic can be found here http://www.macromedia.com/devnet/mx/flashcom/articles/firewalls_proxy06.html

Then there is the option of banning IP addresses. I personally do not like this approach because a lot of the time IP addresses are dynamically assigned and you might lock out innocent users.
Stay safe.