Issue #6: Under Pressure

🎵 Pressure pushing down on me, pressing down on you… 🎵

We developers don’t love to talk about security – until we need to. I’m pretty sure many of us have learned this the hard way, as I have myself. Today, I want to talk about it without (or almost without – you’ll see later) any specific reason, but simply because metaframeworks, being shiny and new, often overshadow the boring yet critical questions like this one. There are plenty of interesting engineering challenges here that we can benefit from exploring, starting with common preemptive best practices and ending with specific problems that need urgent attention in our applications’ supply chain.

The Good

Arcjet is a cybersecurity company that specializes in developing advanced threat detection and response solutions. This might sound like an advertisement or a sponsorship block, but it’s not. As someone with a security background, I’m interested in the work they do, especially in the area of metaframework security, as you might guess from reading this newsletter. Honestly, Arcjet’s approach isn’t my favorite due to a number of opinionated reasons (e.g., their SDK being a separate dependency to maintain, with lots of manual setup, or their aspiration to retire DevSecOps), which are worth a separate longread. However, regardless of the product they sell, their attention to the ecosystem and security best practices is a nice thing to see.

Since they offer first-class support for Next.js, Remix, and SvelteKit, they’ve put together a couple of particularly interesting guides and checklists:

1. Remix Security Checklist. As Remix (or React Router, as we must now say) becomes an increasingly popular way to build robust full-stack applications, this list of security best practices for developers will be very useful for those working with it. It covers dependencies and updates, module constraints, environment variables, authentication and authorization, cross-site request forgery, security headers, validation, and file uploads – essentially, the ins and outs of your typical developer workflow.
2. Next.js Security Checklist. This is a similar set of insights but tailored for the most popular metaframework around, which I don’t need to explain to anyone. Additionally, the Arcjet team has a more detailed writeup on Next.js Server Action Security, which digs deeper into this relatively new feature of the framework. Needless to say, Next.js and Vercel, being production-proven technologies tested for years, pay close attention to security on their own and have their own production checklist. Still, an external perspective is always useful.

Additionally, the Arcjet team maintains an open-source awesome-list dedicated to frontend security, which contains a wealth of insights.

The takeaway here is that you don’t need to be a security professional to keep your metaframework-based app secure. You just need to stick to some proven development practices and pay attention to the insights shared by experts in the field.

Breaking Bad

Security flaws can be found in the most unexpected places in your code. The recent vulnerability found in Vite is a good example of this. Usually, we dismiss such reports, thinking they don’t apply to us, but this one is different:

This vulnerability even applies to users that only run the Vite dev server on the local machine and do not expose the dev server to the network.

The advisory linked above is an interesting read in itself, containing a proof of concept you can easily reproduce if you’re curious. The issue is that, while Vite abstracts away a lot of dev server complexity, the trade-off is the need to understand all the nitty-gritty details in cases like this, as the fix can be quite challenging depending on your setup.

Of course, the Vite team did their best to provide a proper mitigation patch, and here’s how they did it, if you’re interested. This case was particularly intriguing for me because I discovered an awesome CI/CD action in the Vite repository. It shows that each PR is checked against all (or almost all) tools using Vite downstream, from Analog to Waku, including plugins. That’s a very cool, enterprise-level approach that adds an extra layer of trust.

Just days later, the Vite team delivered more good news—version 6.1. This release brings a lot of interesting minor improvements and fixes. In fact, some people are discovering cool features they didn’t know about in the changelog, only to realize they’re slated for deprecation. For me, one of the experimental Vite features I’ve been keeping an eye on is the Environment API, which provides a way to flexibly map client and server environments during build and dev processes. It’s a set of interesting ideas for SSR apps and hybrid rendering, with lots of thoughtful guides already provided for framework and tool authors.

The Noteworthy

Speaking of JavaScript framework authors, GraphQL grandmaster Jayden Seric has just released another one! It’s called Ruck, and, amusingly, it doesn’t need Vite. Or dedicated CLIs. It doesn’t even need Node – just Deno and React. No annoying package.json stories or sophisticated configuration setups – just pure, fresh ESM and import maps, with no build steps. It’s the buildless future we’ve all dreamed of. It sounds suspicious and looks a bit esoteric (for now!), but you can check out the source code for Ruck’s official website to get a sense of it. You’ll find lots of JavaScript modules neatly structured inside the usually empty /public folder. This is another cool proof of concept made possible by Deno v2, and I’m really excited to play with it ASAP.

If you’re wondering why you’d ever leave the comfort of verbose framework-based application codebases, the new episode of the HTML All The Things podcast, titled “Stop Using Frameworks for Everything: Vanilla JavaScript in 2025,”, can shed some light on that. There’s a lot of information on this topic, and we’ve touched on it before, but it’s always good to get another reminder. Who knows? Maybe one day, it’ll help the Ruck team gain another convert. Tools like Ruck are definitely the lesser evil among the alternatives.

If you’re looking for a middle ground between the overhead of over-engineered metaframeworks and the low-level work of vanilla JavaScript, SvelteKit might be your answer. There’s been some interesting discussion lately about middleware support in SvelteKit. Such an improvement would further blur the lines between traditional full-stack apps and metaframework-based apps, opening up new ways to work with server-side code similar to what we’re used to with tools like Express.

No matter which path you choose – the barebones macho JavaScript route or the exoskeleton of some fancy new cyberpunk framework or tool – I hope this issue of Metaframeworks Weekly serves as a good reminder that sometimes we’re at war against adversaries. We need to know all the possible ways to stay safe and be prepared for the next attack. So keep calm, learn the platform, and explore the toolboxes it creates, along with their differences and tool-specific flaws. It will never be a wasted effort.

👋