I'm creating a contest that will allow users to login using their Facebook & Twitter accounts and submit votes on videos. My clients concern is that users will game the system by logging into different Facebook & Twitter accounts to keep spamming votes on the same video.

How can I prevent this type of voter fraud?

  • 5
    So you're worried about social gamers gaming the game? Apr 3, 2013 at 19:54
  • Exactly, my hunch is that there are only so many things I can do to verify that they are not just jumping from account to account. Thoughts? Apr 3, 2013 at 20:04
  • 1
    Great points TidalWave, I completely agree, there is no possible way to make it 100% bulletproof. I apologize if asked the question in the wrong forum. Thanks for your answer though, it will honestly help a ton :) Apr 3, 2013 at 20:23
  • 2
    StackOverflow says that's off-topic there and that it should be asked here. We have another voter fraud thread (security.stackexchange.com/q/30859/836), but it assumes no use of 3rd parties. I'm going to +1 this and see if anybody comes up with something.
    – Jeff Ferland
    Apr 3, 2013 at 20:39
  • 1
    Related question: security.stackexchange.com/questions/33447/… It looks like Facebook at least already do their own multiple-account detection and that it's non-trivial to bypass. I suspect Twitter do something similar but that they would be more tolerant of multiple accounts as long as they are not spamming.
    – Ladadadada
    Apr 3, 2013 at 21:48

2 Answers 2


Rather than logging in to accounts they control, I expect voter fraud would be done by clickjacking or CSRF, harnessing the social viral power of Facebook to attract unwitting accomplices.

With the prevalence lately of images on Facebook that claim that you can obtain a PS4 simply by "liking" and "sharing" an image and the sheer numbers of people who do so, I suspect it would be possible to create something similar that tricked Facebook users into signing up to your site and submitting the voting form.

Another possibility is that the viral image on Facebook could tell them that they had to sign up and vote for a particular entry in your competition to win the PS4.

CSRF has standard mitigation techniques involving nonces, secret keys and MACs. There are mitigation techniques for clickjacking too.

Determining that someone is voting in a particular way for a separate reward is more difficult. Probably a job for an A.I. The first referrer header you see from a client may offer a clue as to their motivation. The amount of time they spend evaluating the various voting options might as well. Choose too quickly and it's probably fraud. You will probably get good data out of tracking mouse movements. These techniques would probably work for your original fear of a single person logging in to multiple accounts.


There is absolutely nothing in the OpenID/OAuth authentication methods that guarantees an individual signing-in through them is indeed a unique user. OpenID provides a bit more data in a form of a certificate (user name, email address, and notary) than OAuth's valet key authentication, but that alone isn't enough to prevent voting fraud. Using the word fraud in this sense is a bit severe in my opinion, maybe abuse is more suitable? Regardless, let's see what other information you could use in your web application and what that means for your voting system:

  • IP address: Not suitable as most users get their IP assigned by a DHCP server and is dynamic (can be assigned to another user later on, or the same user can request a new one), different users might be accessing your website through the same IP (organisations and others using proxy servers, mobile IPv6 users tunneling through an IPv4 broker, and so on), or the same individual could use other means of accessing your website with a different IP (TOR network, VPN,...)
  • Session ID: This consists of a session cookie (or some form of a session persistent request query value in cookie-less sessions), commonly also user-agent string (browser's identification string), and IP that we already covered. None of these (on their own, or session as a whole) guarantee a unique user is signed in as they can simply switch to different browsers, clear user session by deleting cookies, or even change browser's signature. All of which can invalidate the user session and a request for a new one would be made.
  • Referral string: Not suitable on its own as it can easily be spoofed or simply reused many times.

This leaves you at either:

  • Trusting Facebook and Twitter to do their own detection of multiple per-user accounts,
  • Requesting an additional user authentication that would try to detect such abuse (might be impossible to do any better than what is already in place with Facebook and Twitter),
  • Change to voting with a ballot (invitation only one-time voting), or
  • Account for possible voting abuse when presenting results (such as weighted averages).

All latter three options are rather tricky to implement and might not be within your project's budget, which is - at the end of the day - the most decisive factor on which of these options could or should be implemented.

On a side note, I wanted to give you a good example for the weighted average, but the problem is that all systems that care about the validity of these methods intentionally don't publish their inner workings, to prevent further abuse by circumventing the system in place. One of the websites that uses such voting mechanics and is known to put a lot of effort into it is IMDB (you be the judge on how effective that is, I'll reserve my comments), and there are many others with altogether different implementations. Even StackExchange has some sort of serial voting prevention, but details about it are also rather scarce.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .