While working on frontend security projects, I encountered Blazor - here's what I learned.

Have questions? Feel free to ask in the comments section below.

正文

Low-level software protection engineer with 20+ years in native and managed code security. Creator of ArmDot, protecting commercial .NET applications since 2014.

Blazor WebAssembly Obfuscation: Protecting Client-Side .NET Code

Open the network tab in Chrome DevTools while loading a Blazor WebAssembly application. You will see a sequence of file requests - the .NET runtime, the application assemblies, the dependencies. Every one of those files is being downloaded to the browser. Every one of them contains your compiled .NET code. Every one of them can be saved, opened in ILSpy, and read.

This is not a misconfiguration or a security oversight. It is the fundamental architecture of how Blazor WebAssembly works. Understanding what that means for your application is the starting point for protecting it.

Blazor Server is a completely different story A note on the platform itself

Blazor-specific failure modes when applying obfuscation

When a user opens a Blazor WebAssembly application, the browser bootstraps a .NET runtime implemented in WebAssembly, then downloads your compiled assemblies to run them client-side. The entire application - your business logic, your algorithms, your string literals, your component hierarchy - executes in the browser rather than on a server.

In .NET 7 and earlier, the assemblies were served as standard

files. Any browser developer tool or download manager could save them directly.

In .NET 8 and later, Microsoft changed the delivery format. Assemblies are now packaged as

files using the Webcil format - a WebAssembly wrapper around the standard .NET assembly. The file extension changed. The content did not. A

file from a Blazor application can still be loaded into a .NET decompiler. The IL is still there, the metadata is still there, the string literals are still there.

The exposure is the same. The packaging is different.

Blazor WebAssembly supports ahead-of-time (AOT) compilation, which compiles the IL directly to native WebAssembly bytecode before deployment. This is sometimes cited as making the assembly exposure less relevant.

It does not. Even with AOT compilation enabled, the original .NET DLL files are still shipped alongside the compiled WebAssembly. This is documented by Microsoft: Blazor requires the DLLs for reflection metadata and to support certain .NET runtime features. The AOT-compiled

More Details

There are a few more points worth noting. First, browser compatibility varies across different browsers. Second, performance optimization is crucial when handling large amounts of data. Finally, key management is also an important consideration.

That's all for this comprehensive guide. I hope you found it helpful! Feel free to leave comments if you have questions.

Reference: Blazor WebAssembly Obfuscation: Protect Client-Side .NET

I've had several readers ask me about Introducing recently, so I decided to write a comprehensive article about it.

Ready to learn more? Subscribe to our newsletter for weekly tutorials and tips.

正文

Protecting data that’s sensitive (such as personal health or financial information) is crucial to building applications that users trust. But getting access control right is a tricky business. Complex requirements and a plethora of tools, as well as performance considerations, can kill dev team productivity.

Stack supersedes Protect.js — same project, renamed and expanded. For new projects, read the current product announcement instead:

Protect turns data access control on its head by protecting data directly.

Unlike complex, application-specific frameworks or hand-rolled tools, Protect.js makes building secure, data-driven applications simple so you can deliver services that users trust without slowing down delivery.

Security experts say you shouldn't roll your own crypto but it's ok, we've done the hard work for you.

Protect’s power comes from the strongest form of access control: encryption.

Encryption is rarely considered for the fine-grained protection of data because it's hard to implement, slow, and doesn’t play nicely with other tools in the stack like identity providers or the database. That is, until today.

Based on the CipherStash encryption SDK and using our revolutionary key management service,

, Protect.js unlocks the power of encryption but without the hassle. Protect.js:

Works with any Node.js framework or ORM (like Next.js + Drizzle)

Is based on AES-256 encryption and uses formally-verified cryptography

Uses ZeroKMS key management that’s up to 14x faster than AWS KMS

Is so easy to use you can get started in ~under 15-minutes~

but these approaches are only part of the story when it comes to effective data protection.

At-rest and in-transit encryption leave critical gaps in your data’s defenses which can lead to vulnerabilities or accidental leaks and make it harder to reason about whether data is secure, especially when trying to convince customers or an auditor. Protect.js uses encryption

More Details

There are a few more points worth noting. First, browser compatibility varies across different browsers. Second, performance optimization is crucial when handling large amounts of data. Finally, key management is also an important consideration.

That's all for this comprehensive guide. I hope you found it helpful! Feel free to leave comments if you have questions.

Reference: Introducing Protect.js

I've been researching The for a project, and here's a summary of what I found useful.

Ready to learn more? Subscribe to our newsletter for weekly tutorials and tips.

正文

Java is one of the most widely used programming languages in the world, powering everything from enterprise applications to web browsers. Java is unique in that it is a compiled language that runs on a virtual machine. This means that Java applications can run on any platform that has a compatible java virtual machine (JVM) installed. But with its popularity comes a specific set of security challenges that enterprises must address to protect their systems and data. The JVM itself is a potential attack vector. Attackers can exploit vulnerabilities in the JVM to bypass security controls and execute arbitrary code.

Let’s explore three key challenges and how to address them.

Because Java is compiled into bytecode, it presents as regex — which looks unreadable to most people and requires a deeper level of domain knowledge to effectively secure. Cybersecurity teams must be able to understand the intricacies of the Java language and its execution environment to properly protect against threats.

One of the most difficult aspects of Java is its architecture, which allows for dynamic code loading at runtime. Attackers can use this feature to inject malicious code into Java applications and circumvent traditional security measures. Cross-site scripting (XSS) attacks on Java applications can also allow attackers to execute arbitrary code on a victim’s computer.

An XSS attack occurs when a bad actor injects malicious code into a web page, which is then executed by unsuspecting visitors to the compromised site. This can allow the attacker to steal sensitive information such as passwords, session tokens, or other user data. Java applications are particularly vulnerable to XSS attacks because they often rely on user input to generate web pages.

Another challenge is the sheer size of the Java ecosystem. The Java Virtual Machine (JVM) is used by millions of developers worldwide, and there are thousands of third-party libraries and frameworks available for Java. This makes it difficult for enterprises to keep track of all the dependencies in their Java applications and ensure that they are secure.

This is how Log4j took over the internet in November 2021. Log4j was a widely used library for logging in Java infrastructures, which means that essentially any company with Java applications was affected. Because so many businesses rely on Java applications, simply turning them off would have been detrimental to their system’s functionality.

With those challenges laid out, it may seem daunting. But you do not have to hire a team of java experts who have spent years learning the nuances of a language written in bytecode. Besides, most Java experts become developers, not security specialists. And in any case, such a team would cost millions of dollars per year to operate.

implement security platforms into your strategy that are built for Java from the ground up. By using these, you can ensure that your Security Platform is specifically designed to address the unique security challenges faced by enterprises that use Java.

One of the key features of such products is their ability to detect and prevent attacks that exploit the dynamic loading of code in Java applications. They can intercept and analyze all calls to the JVM (Java Virtual Machine), allowing them to detect and block any attempts to inject malicious code into a Java application.

Consider also implementing a rules engine that enables your enterprise to define custom immutable security policies for your Java applications. This allows you to easily manage and enforce security controls across your entire Java application portfolio, regardless of the complexity of the application or the size of the ecosystem.

In addition to its security benefits, by using a lightweight agent that sits within the JVM, a java-specific platform can provide real-time protection without impacting application performance or requiring any changes to the application code.

To get started implementing Java-specific application security instantly, click here.

More Details

There are a few more points worth noting. First, browser compatibility varies across different browsers. Second, performance optimization is crucial when handling large amounts of data. Finally, key management is also an important consideration.

That's all for this comprehensive guide. I hope you found it helpful! Feel free to leave comments if you have questions.

Reference: The JVM Problem: Java Programs Require Java-Specific Security