These days, it’s all too easy to think of the internet as a collective of ‘angry old men’ tropes. Comment sections on social media or the classic ‘grumpy Redditor’ tend to skew our sense of what digital communities are like, leaving us with a sense that the internet is, while useful, not the friendliest or warmest place to be.
But here’s the thing: there are plenty of incredible pockets of people, entire communities, online who are committed to genuinely helping one another, offering resources for very little money (or nothing at all), and sharing knowledge across oceans that would once upon a time have been buried in a university library accessible only to a few hundred people.
Open-source and creative coding platforms are a wonderful example of this. Platforms like WordPress have enabled many people to create their own website in an environment that promotes openness, with user-generated code being shared between huge communities of users and contributors. It’s a great way to make advanced coding and output accessible to those who only have limited time and understanding, creating space for a much more creative approach to coding than the point-and-click website builders offer.
But open-source is inherently risky, despite plenty of frameworks in place that seek to reduce that risk. Here’s why.
Cross-site scripting (XSS)
This is a vulnerability that can enable attackers to acquire huge amounts of private customer data via your own website. An XXS is able to hide behind the legitimacy of a website within a malicious script, exploiting user trust and gaining access to anything that user already has access to. So, if a user has sensitive information like passwords, security questions, or address and credit card information saved in their account, the XXS can access all of those things too without the browser being able to identify that the script comes from an untrusted source.
Community-contributed code can be ‘laced’ with malicious script, and many people simply aren’t equipped to recognise that – or even realise it’s a risk.
Code injection
When code is made public, that means everyone can see it – including hackers. It’s relatively common for them to scrutinise this open-source code for vulnerabilities that they can exploit, which puts everyone who uses it at immediate risk.
They can also compromise dormant libraries. What appears to be a run of the mill update may actually be malware that was able to be planted because no one was keeping a close eye.
Because these platforms are built around sharing and remixing, a booby-trapped project can spread quickly: someone forks a popular sketch, unknowingly inherits the hidden malicious code, and now anyone who views their fork is exposed too.
Vibe coding and a false sense of security
When you ask an AI tool to write code, it often volunteers a claim about that code’s licensing status. It might say something like “this snippet is MIT licensed” or “this is freely usable, no copyleft restrictions” alongside the code it gives you. The problem is that the AI doesn’t actually know this. It’s not checking a real license file or verifying provenance, just providing a plausible-sounding statement (which is, in fact, the same way it generates the code itself).
People are increasingly trusting an AI’s unverified say-so about licensing instead of doing the actual verification work, which could expose them to real intellectual property or licensing violations.
Staying ahead of the attackers
Frameworks and good intentions only go so far when the whole point of open-source and creative coding platforms is that anyone can contribute. They need to be actively hunted for.
This is where a penetration testing platform earns its keep. Rather than waiting for a malicious script to surface in production, a pen test simulates the exact behaviour described above: probing for injection points, testing whether forked or community-submitted code can execute in ways it shouldn’t, and flagging dependencies or licensing claims that don’t hold up to scrutiny. For platforms built on openness and remixing, that kind of testing needs to happen as often as the community itself changes.