Be carefull with what Javascript integrations you add into your Phoenix project

Professionally I am a Developer Advocate for Security and I would like to call the attention of all developers to not blindly trust in the Javascript they add to their Phoenix applications.

See this recent study:


According to research from Tala Security, techniques such as Magecart attacks, formjacking, cross-site scripting and credit card skimming are exploiting vulnerable JavaScript integrations running on 99% of the world’s top websites, and security effectiveness against JavaScript vulnerabilities is declining.

Keith Geraghty, solutions architect at Edgescan, said that Javascript is not the issue here, as it has “revolutionized the user experience on the web.
“When we refer to vendors, we are usually referring to talented programmers who have developed tools and solutions that, along with HTML and CSS, make up the backbone of the web,” he said. “Like with all plugins and solutions, organizations need to ensure that what they use is safe, up-to-date and falling under the same controls as their traditional patch management strategy.”

Craig Young, senior security researcher at Tripwire, said: “The situation with loading so many JavaScript libraries from so many different domains greatly amplifies the risk subdomain hijacking attacks pose to the internet at large. The problem is that each third-party domain supplying unauthenticated JavaScript presents an opportunity for a server compromise to serve malicious content to unsuspecting users unless the site operator has taken specific security precautions.”

So I am not advocating to not use Javascript, but to be really careful with what you include.

My mantra is that if is simply enough I may code it myself or copy the code to my project.

For more complex things I just audit the code and if I am happy I will require the exact version, thus it is locked and not vulnerable to the introduction of malware in subsequent versions. Yes you read well, malware, unfortunately it happens. I then subscribe to notifications for new releases and every time a new security update comes along I will need to repeat the audit process and lock the new version.


FTFY. It is about all applications, not only Phoenix.


Yes it’s about all applications…

I just used Phoenix word because we are in the Phoenix forum :slight_smile:

No intention to say that only affects Phoenix :wink:

For example there is an unsafe code evaluation issue with AlpineJS that prevents me to use it right now. But it seems that they are working on this problem.

1 Like

I think it’s wrong for Phoenix projects to include webpack by default. It requires crap like npm and Node.js, and encourages using them also to include JavaScript into the project.

Default should be to not include anything JavaScript related, and then offer option to include e.g. webpack if needed.

1 Like

I am also off the same option, but Chris needs to go the route of de Developer convenience, otherwise Phoenix would never gained so much traction.

Unfortunately in Software Development convenience is in the majority of the cases above security, and this is a very hard mental model to change in peoples mind. Even the ones that had been bitten by security incidents, still resist the change… I have seen this in the past with my own eyes.


I completely agree with the original post but the problem is, many people just need to do a task and move on. :frowning:

Nothing much can be done about it, especially having in mind that security is a 3rd class citizen in most teams.

1 Like

That’s exactly one of the reasons the internet is so broken, and so many security incidents occur every day… Security is not in the core of the software life cycle from day zero, it’s an afterthought, when is not completely ignored :frowning:

Has uncle Bob says, the day that developers will be legally responsible for the code they write is coming, and I have no doubt about it. It can take one or two decades, but If the ecosystem continues downhill in terms of security, then the day you can be charged in court by that line of code you wrote that killed someone, made damages, caused a security incident, etc. will be a reality, and then I will not want to be a developer, but I am curious to see if developers will continue to do as they do now:

1 Like

Well don’t get me wrong. I absolutely believe we should invest much more in security upfront. And I am looking forward to companies being sued for security incidents.

The system being as broken as it is though, likely some poor schmuck that has a family to feed and is not sure if they can land another job if they get fired, will likely be sued, and not the manager who gave the order.

Don’t forget that most of the programmers simply obey management’s orders.


And that is exactly what I am expecting that will happen, and the reason why I don’t want to be a developer on that times.

1 Like