Arcjet

??? Discover how #WebAssembly enhances application security → https://goo.gle/40KRBVt Join Arcjet's CEO, David Mytton and Thomas Steiner, PhD on the #WasmAssembly podcast as they delve into Arcjet’s innovative use of #Wasm for bot detection, rate limiting, data redaction, and more, providing a manageable security toolkit.

I discussed on the latest WebAssembly podcast how we generate all of the Arcjet Wasm using open source tools. It's just `cargo build` from Rust and jco for JS (as the successor to wasm-bindgen). WIT for cross-platform generation has been working well, thanks to the work from the Bytecode Alliance

Great chatting with Danny Allan on the Snyk Secure Developer Podcast. Why don't developers care about security? Where do you install the monitoring agent in serverless environments? How can Wasm help?

If you need to be PCI DSS v4.0 compliant then a WAF is required, but what about other types of application? Is there anything special about Next.js that means it wouldn't benefit from a WAF? No. Just don't bother with a network level WAF...

How can you avoid maintaining dependencies? Don't use them in the first place. Everything you need to build and serve a dynamic website is in the Go standard library: embedded static files, compiling?dynamic HTML templates,?structured logging,?SQL drivers for common databases,?runtime traces...

Another release - not everyone is off for the holidays yet! We're adding more detailed verification options for developers where every request will be checked behind the scenes using published IP and reverse DNS data for common bots. Bot detection is never perfect, but this improvement helps protect against spoofed bots where clients pretend to be someone else. For example, we can detect if a client is really Googlebot by checking if the request IP is within?Google’s published IP ranges. Available now!

Using Wasm requires bindings to cross between host and guest. Working these by hand is fine for 1 language, but what about 2, or 5, or 10? Then you get into the world of automated codegen and have to ask: should code be generated to feel more natural to the language or it can be a more direct mapping to the Component Model types. Neither option fits 100% of use cases so it is up to the tool authors to decide which makes the most sense. Developers may struggle with non-idiomatic patterns, leading to verbose, less maintainable code. Using established conventions makes the code feel more familiar, but does require some additional effort to implement. We decided to take the idiomatic path to minimize friction and make it easier for our team so we know what to expect when moving around the codebase.

Introducing Nosecone: an open source library to set security headers like Content Security Policy (CSP) and HTTP Strict Transport Security (HSTS) on Next.js, SvelteKit, and other JavaScript frameworks using Bun, Deno, or Node.js. Whether you’re adapting to the stricter security header requirements of PCI DSS 4.0 which comes into force in 2025 or are simply looking to enhance your app’s security, Nosecone offers: - A type-safe API with pragmatic defaults. - Middleware adapters for Next.js. - Config hooks for SvelteKit. - Easy integration with web servers in Bun, Deno, and Node.js.

This is how we used Astro's Starlight framework to build our documentation with support for framework switching, a custom sidebar, and a custom table of contents for improved SEO and a better user experience. Documentation is the product and we spend a lot of time on it! We initially started with?Nextra, a docs framework for Next.js, however, we found it to be too inflexible and difficult to customize. After some evaluation, we turned to?Starlight: a needs-no-presentation, content-driven?Astro?docs framework. This has been a very flexible choice with virtually no friction in adoption, serving us well until recently. However, as our SDK started to?add support for different frameworks, developing its functionality and increasing features, we realized that the docs structure was becoming defective and painful to work with. Read more on our blog (link in comments)!

Today we're announcing support for NestJS and Remix! We started with the Next.js framework which used our underlying Node.js SDK. The core functionality lives in the runtime SDK, which we extend with the framework specific adapters to make them feel native. The result is that using the Arcjet?[Next.js | SvelteKit | Node.js | ...]?SDK feels like programming against a native?[Next.js | SvelteKit | Node.js | ...]?API. If we don't have a framework SDK you can still use the runtime language SDK, but it requires a bit more work. So today we're announcing support for both?NestJS?and?Remix?which now have their own native Arcjet adapters! That brings us support for Bun, Deno, Node.js, Express, Hono, Next.js, NestJS, Remix, and SvelteKit. More on the way!