Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm developing a JS widget that can be embedded by 3rd party websites. When widget is shown, it sends request to my site. When this request is received, I know that it was shown to the user and pay website for this view. So I don't want to pay if widget is rendered not at the target website.I think that to verify site's url, I need to send embedding page's url in request parameter when widget is rendered. However, it will be possible to send such request from any place, not only from this site's page.

Is it possible to verify url where widget was placed?

share|improve this question

As an alternative to having the widget "report back to home," you could write a simple robot that crawls the websites and verifies that the the websites are indeed hosting the widget.

To avoid fraud, you would build the robot with the following considerations:

  1. Hidden identity. Make sure the site isn't only serving widget to robots by disguising your robots identity.
  2. Random crawl sampling. Ensure that your crawling uses a random sampling for when you crawl the sites. This prevents a site from anticipating the crawl and serving it only during that time.
  3. Verify that the widget is visible. Don't only check for the existence of the widget, but that the widget itself is visible and not hidden.
  4. Manual overview. Have your robot generate screen captures so you can review manually whether the widget is appearing.

There are some inherit difficulties that you will be faced based on the "pay-per-view" nature of leasing (to what extent, I do not know because I don't know the specifics of your agreement). The biggest problem is not people placing the widget in non-authorized URLs, but rather abusing the system by automatically (fraudulently) crawling the site to boost view counts. That should be your primary concern, as it is where the majority of the fraud will stem from.

The problem is, it is difficult to verify the legitimacy of a view from an embedded widget. With only access to JavaScript, you have limited capabilities for differentiating between a robot, a user constantly hitting refresh, and a legitimate user. Without access to the server side, your best option to prevent fraud is through browser fingerprinting. This will assist you monitoring abuse of your widget via constant refresh, et al. It is not a catch-all because it is still vulnerable to no-js / torbutton users which can spoof identities, but it does provide a good first-level of protection to repeat view fraud.

share|improve this answer
It won't prevent from embedding widget to another sites. As I said, I pay to site for each widget show so I want to actually verify that this show was at valid site where widget was intended to be. – Andrei Botalov Oct 3 '12 at 18:07
Are you referring to pay-per-view? As in, you want to verify that each reported view you're paying for is a legitimate customer? If so, you are fighting a very uphill battle (and perhaps one that cannot even be won). – Moses Oct 3 '12 at 18:11
Yes, I pay per view – Andrei Botalov Oct 3 '12 at 18:13
Re-reading your comment, it actually appears that you want to verify that the URL you paid is the one hosting, correct? If so, that is precisely what my suggested robot would do. Just point the robot at the sites you are paying and monitor their usage. – Moses Oct 3 '12 at 18:15
Code for creating widget may be placed to several places. The easiest attack may be to place this widget to localhost and then reload it many times. But I don't want to pay for such requests as it's not even rendered on site where it should be. There is no problem for me if widget isn't placed at traget site (No views => No pay). There is a problem if it will be placed somewhere else except target site. – Andrei Botalov Oct 3 '12 at 18:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.