Check your cloned repos. Seriously.

It’s a moment every open-source developer dreams of. You create something you think is useful, you put it on GitHub, and people actually start using it. They star the repo, they fork it, they build things with it. It’s a feeling of shared success and community contribution.

A while back, I built and released nextjs-better-auth, a starter kit to help developers quickly implement a robust authentication system in their Next.js projects. My goal was simple: contribute to the open-source community and save other developers some time. I deployed a demo to Vercel and, for my own curiosity, added a simple, privacy-friendly script from Umami Cloud to the demo site.

The project got some traction. A few stars here, a few forks there. It felt great.

Then, one day, I checked my Umami dashboard and saw a new domain sending traffic. It wasn’t the usual localhost or a random Vercel preview URL. It was portailmfa.com.

A quick search showed it to be an official-looking portal based in Algeria. They were using my starter kit. And they had forgotten to remove the script.

The “Uh Oh” Moment

Let me be clear: Umami is not a malicious tool. It’s a fantastic, privacy-respecting platform. It doesn’t collect personal data or track users across sites.

My initial reaction was a mix of flattery and alarm. It’s incredible to see your code being used in an official capacity. But it’s also a stark reminder of the responsibility that comes with sharing code. This wasn’t a “hack” or a security breach. It was a simple oversight. A developer, likely on a tight deadline, cloned the repository, built their application on top of it, and never thought to check for third-party scripts in the layout file.

This incident is the perfect, low-stakes case study for a lesson every developer needs to take to heart.

The Golden Rule: Always Check the Code You Copy

We all do it. Whether it’s a Gist, a Stack Overflow answer, or a full-blown starter kit from GitHub, we build on the work of others. That’s the power of the open-source ecosystem. But this efficiency comes with a critical caveat: you are responsible for every line of code in your final product.

Cloning a repository isn’t just downloading a set of features; it’s inheriting a set of decisions, dependencies, and configurations made by someone else.

Here’s why you should treat every git clone like you’re inspecting a used car:

1. Hidden Scripts: My situation is a prime example. Harmless in this case, but what if it was Hotjar (with session recording), or a more invasive marketing pixel? You could be unintentionally leaking user data to a third party.
2. Security Vulnerabilities: A starter kit could have outdated dependencies with known vulnerabilities. It could contain poorly configured security headers or, in a worst-case scenario, malicious code intentionally hidden to skim API keys or user credentials.
3. Configuration and API Keys: Many developers forget to remove placeholder API keys or configuration settings from boilerplate code, which can lead to errors or, worse, security risks if they are connected to a public service.

Your 5-Minute Due Diligence Checklist

You don’t need to perform a line-by-line audit of React’s source code to use a starter kit. But you should spend five minutes checking the boilerplate you’re adopting.

Here’s where to look in a typical Next.js project:

• package.json: Look through the dependencies and devDependencies. Do you recognize them? Are there any libraries that seem out of place? A quick npm audit can also surface known vulnerabilities.
• The Main Layout File (layout.tsx or _app.tsx): This is the most common place to find third-party scripts. Look for any <Script> tags. In my project, the Umami script was right there.
• .env.example or .env.local: Check what environment variables the project expects. This gives you a clear idea of the external services it’s configured to connect to.
• API Routes (/app/api): Quickly scan the API routes. Are they connecting to databases or services you don’t recognize?
• Read the README.md: A good project maintainer will often include a note about removing demo code or changing configurations.

Conclusion: Trust, but Verify

The open-source community thrives on a foundation of shared trust and collaboration. My nextjs-better-auth project was my way of giving back, and I’m thrilled that it has been useful to others, including the team behind portailmfa.com.

This experience wasn’t a disaster; it was a powerful, and slightly surreal, reminder that the convenience of open source doesn’t remove our responsibility as developers. It reinforces it.

So, to the developers using my starter kit: thank you! I’m honored. Now please, go and remove that script.

And to every developer out there: the next time you clone a repo, take a moment. Pop the hood. Check the engine. Your users will thank you for it.