Arcjet

How did 11 lines of code cause a breach of tech giants like Facebook, PayPal, and GoDaddy? Do you really need to use jsarray which was introduced natively in JS in 2009, but still has >400 million downloads/month. Trivial packages don't have a trivial impact so should be avoided

Lessons learned running WebAssembly in production with Go & Wazero - The convention of not committing binary files to git falls apart with Wasm files. Embedding hex-encoded byte arrays in Go breaks VS Code and makes it difficult to review PRs. Using `go:embed` works nicely instead. - Using Wazero's CompiledModule is a tradeoff between startup times (slower if compiled) and an order of magnitude improvement in runtime performance. Our API response time p50 is 10ms and we aim for a p99 of 30ms, so this really helps. - We use Wizer to pre-initialize at build time. This instantiates Wasm, executes any init functions, then snapshots the state into a new Wasm module which is what we load at startup. - Running wasm-opt over the generated Wasm binaries applies additional optimizations such as flattening the internal representation and rewriting the control flow graph. Again, you have to trade off against slower build times. - For the @arcjethq SDKs, we want to balance both. We don’t want to ship huge SDKs and the startup time is important to minimize in serverless environments with cold starts. For long running servers like a classic Node.js Express server we can lean more towards performance vs binary size, but we still don’t want our users to experience slow startups. On our own servers, we can optimize heavily for performance. - Profiling is still difficult. None of the normal performance tracing tools we use can inspect the Wasm code from Go. We use OpenTelemetry instrumentation and all we get to see is the top level Go function call. wzprof looks like a promising profiling solution built on top of wazero.

Building our Netlify extension with their new SDK incorporating Tailwind and tRPC enabled us to easily create a native UI within the Netlify dashboard. Bot protection. PII detection. Attack prevention. All integrated.

Block all AI bots except one? It's easy to customize Arcjet because it's just code

Environment variables are convenient but leave secrets exposed. What should you do instead?

When it comes to securing your logs, how you redact sensitive data matters. Relying on a deny-list can be risky. Here’s why switching to an allow-list is a smarter choice 👇 1️⃣ Deny-Lists Miss New Fields A deny-list only redacts what you’ve specified. If you add new fields and forget to update the list, sensitive data can slip through unredacted, exposing you to security risks. 2️⃣ Allow-Lists Provide Full Control An allow-list ensures that only the fields you explicitly approve are logged. New fields are excluded by default, so there’s no risk of accidentally logging sensitive information. 3️⃣ Reduces Human Error With a deny-list, every change to your data structure requires updating your redaction rules. An allow-list minimizes this risk by logging only what’s safe, reducing the chance of human error. 4️⃣ Simpler to Maintain Maintaining a deny-list can be complex, especially as your application grows. An allow-list simplifies this by focusing only on what should be logged, making your logging strategy easier to manage. 5️⃣ Stronger Security Posture By default, an allow-list approach enhances your security. It prevents the accidental exposure of sensitive data, keeping your logs clean and secure from the start.

Simplify your app's security with Arcjet. Customizable protection for signups, logins, and APIs is just a few lines of code away. Protect your app now: https://loom.ly/CbtcTmM

Test security without the risk. Arcjet lets you simulate and perfect your security rules locally before going live. Keep your production safe—get started today: https://loom.ly/CbtcTmM

Rate limiting is crucial for protecting your app from abuse. Without it, your app is vulnerable to brute force attacks and API overloads. Here are 3 reasons why your apps should be rate limited: 1️⃣ Prevent brute force attacks Limit the number of login attempts per user within a set time frame. Example: Allow only 5 login attempts in 5 minutes to block attackers trying multiple password combinations. 2️⃣ Avoid API overload Restrict the number of API requests a client can make per minute. Example: Set a limit of 100 requests per minute to ensure your API isn't overwhelmed, maintaining stability for all users. 3️⃣ Implement usage quotas Enforce daily usage limits based on user tiers. Example: Allow free tier users to make up to 1,000 requests per day, preventing resource exhaustion and ensuring fairness across all user levels. Implementing rate limiting is vital for app security and performance. Make sure your app is protected and your resources are fairly distributed. Learn more it here: https://lnkd.in/eRcFauhJ

Developers, it's time to take ownership of app security! Neglecting security during development leaves apps vulnerable and leads to last-minute surprises. Here are 5 key ways to integrate security into your workflow: 1️⃣ Shift-left security practices Traditionally, security was an afterthought. The shift-left movement pushed developers to focus on security earlier in the development cycle. Ingraining security in every line of code reduces vulnerabilities and aligns development with security goals. 2️⃣ Power of application-level context Network security is essential but lacks insight into application logic. Developers can apply more nuanced, context-aware security measures like rate limiting based on user roles or business needs. Context enables better protection without compromising user experience. 3️⃣ Testability of security rules When security is part of your codebase, you can test it like any other function. Automating security rule testing, like bot protection or rate limiting, ensures robustness and reliability across environments, preventing nasty surprises in production. 4️⃣ Benefits of owning security By owning security, developers enjoy faster development cycles, better protection for different user types, and a security-conscious team culture. It also leads to fewer issues when pushing code to production, making the entire process smoother. 5️⃣ Balancing app-level and network-level security Application-level security doesn’t replace network-level protections—it complements them. Use app security for nuanced, business-aligned decisions while relying on network security for large-scale attacks. The best approach leverages both together. Taking ownership of app security empowers developers to write more secure, testable code. Learn how to apply these practices and protect your applications effectively: https://loom.ly/JwzyFyc