"How to Prevent Clickjacking Attacks in Your Meteor App"

This was awesome. I added it to my app immediately. Go Meteor!


I did the same.
Why it is not a standard package when creating a new project?


Probably because not everyone has iframes on their page.

I could be wrong, but I think the exploit is for someone to send you an email that looks like a link to a legit web app, but is really a link to the hacker’s site. E.g.

<a href="www.fakesite.come">site name of a legit site</a>

fakesite.com has an iframe in it that displays the legit site. And it has js on it that captures your username and password, etc.

Ahhh interesting. Thanks for explaining that!

1 Like

Glad it helped! It’s super easy to use the package to avoid this issue :slight_smile:

I can ask to put this package as standard when you create a new meteor app. I think it would be helpful for others

1 Like

I vote for it.
I don’t have any data, but I think the percentage of meteor projects embedded in an iframe is way smaller than the ones that can get protection from it.

1 Like

Once upon a time, the main package browser-policy was a candidate for deprecation because of equivalent npm packages that are more robust and have more features being offered.

We are using this package but I just don’t know what happened to the discussion of deprecation

indeed it was under discussion on this PR Update Guide to make Helmet the official recommendation for HTTP Headers by toinevk · Pull Request #750 · meteor/guide · GitHub

but also browser-policy was restored to the docs and still is the recommended package Restore browser policy page by coagmano · Pull Request #622 · meteor/docs · GitHub

1 Like

I don’t believe any modern browsers allow you to access the data being inputted into an input inside a cross-domain iframe, but it is possible to place a layer over the iframe and accept the data entered into transparent inputs in the outer window. Maybe someone can confirm?