What Is Code Access Security

What Code Access Security means

Code Access Security (CAS) was Microsoft’s .NET security system for limiting what code could do. It was designed to stop untrusted or less-trusted code from carrying out privileged actions, such as reading protected files or using other restricted computer resources.

The key idea was simple: code did not automatically receive every permission available to the application or computer. The .NET runtime could inspect the code’s identity, origin, and other evidence, then decide what that code was allowed to access.

So, if you’re asking what is code access security, the short answer is:

> CAS was a .NET Framework mechanism that used information about code to control its permissions.

The word “code” matters here. CAS was mainly concerned with the identity and trust of the running code itself. It was different from checking who a user was.

CAS is also different from a security access code. That phrase usually refers to a passcode or similar credential. It isn’t the name of the .NET permission system.

Why .NET used Code Access Security

Software often runs with access to resources that could cause harm if misused. Depending on the application, those resources might include:

• Files and folders
• Network connections
• Environment information
• Unmanaged system resources
• Other protected parts of the computer

A piece of code could be unsafe because of where it came from or because it had not been given enough trust. The original .NET Framework needed a way to make finer-grained decisions than “the application can do everything” or “the application cannot run at all.”

CAS provided that middle ground.

For example, an application could run code while limiting that code’s ability to perform certain operations. Code with one identity or origin might receive more permissions than code with another. The runtime used those differences when deciding whether a protected action should be allowed.

This made CAS part of the Common Language Runtime (CLR). The CLR is the part of the .NET Framework that runs managed code and provides services such as memory management, type safety, and runtime security checks.

In that setting, CAS was intended to reduce the damage that untrusted code could cause. It was an early form of evidence based security, meaning security decisions were based on facts about the code rather than only on the person running the application.

That might include facts such as:

• Where the code came from
• What identity the runtime associated with it
• Other characteristics, called evidence, that helped describe its trust level

CAS did not mean that every action by every assembly was automatically safe. It was a permission system used by the runtime to make access decisions.

How CAS evaluated code identity, origin, and evidence

CAS treated code as something that could have an identity and a level of trust.

Code identity refers to information that distinguishes one piece of code from another. Origin refers to where the code came from. The runtime could use these and other facts as evidence when deciding which permissions applied.

Imagine two pieces of managed code:

1. Code installed as part of a trusted application.
2. Code brought in from an outside location.

Under the CAS model, those pieces did not have to be treated as equally trusted. Their origin or other evidence could affect the permissions assigned to them.

The decision process can be pictured like this:

1. The CLR identifies the code.
2. It evaluates the code’s available evidence.
3. That evidence is matched against security policy.
4. The code receives, or is denied, certain permissions.
5. A request for a protected action is checked against those permissions.

This is why CAS is sometimes described as identity-based security for code. The runtime was not looking only at the user account. It was also asking, in effect, “What code is trying to do this, and what do we know about it?”

The exact policy and permission behavior belonged to the older .NET Framework security model. It should not be treated as a description of how modern .NET handles application security today.

Permissions and protected computer resources

A permission is an approval to perform a particular kind of action. In CAS, permissions represented access to protected resources or operations.

A permission might control whether code could:

• Read from a file
• Write to a file
• Connect to a network resource
• Access a protected system feature
• Perform another privileged operation

The important distinction is between running code and allowing every action that code requests. CAS was intended to let code run with limits.

For example, an application might need to process data but have no reason to write files outside a specific location. Under a permission-based model, the application could grant the code only the access it needed.

That sounds similar to the general security principle of least privilege: give code only the permissions required for its job. CAS applied that idea through the .NET Framework’s code permission system.

Still, CAS was not the same thing as every form of operating system protection. It was a runtime mechanism. It depended on the .NET Framework security model and its policies. It was not a universal replacement for file-system permissions, network controls, account security, or safe application design.

A simple Code Access Security example

Consider a desktop .NET Framework application that loads a library from outside the application’s trusted installation.

The library’s job is to parse a document. It should not need to create files in protected folders.

A conceptual CAS policy might treat the library as less trusted because of its origin. When the library tries to write to a protected location, the runtime checks whether the code has the required permission.

The result might look like this:

• The library can run its document-parsing code.
• It can work with data passed to it.
• It cannot write to a protected file location without the necessary permission.
• The application can respond to the denied operation.

This is a Code Access Security example, not a recommended design for a new application. It shows the original idea: the code’s origin and identity influence what it may do.

Another way to express the same example is:

> “This code may execute, but it does not have permission to perform that protected action.”

That is the difference between a code permission decision and a simple application-wide allow-or-deny rule.

How CAS differs from authentication, authorization, and access control

These terms are related, but they answer different questions.

Authentication

Authentication asks:

> Who are you?

A login, password, certificate, or other credential can be used to identify a user or service. Authentication establishes an identity.

CAS was not mainly a user login system. It focused on the identity and evidence of code running inside the .NET environment.

Authorization

Authorization asks:

> What are you allowed to do?

After a system knows who a user or service is, it can decide whether that identity may read a record, edit a resource, or call an operation.

CAS also made permission decisions, so it is related to authorization in security. The difference is what is being evaluated. Traditional authorization often evaluates a user, service, role, or claim. CAS evaluated code identity, origin, and related evidence.

Access control

Access control is the broader idea of controlling access to resources. It can include user permissions, service permissions, operating system rules, application checks, and code-level restrictions.

CAS was one form of access control inside the older .NET Framework model. It was not a list of four fixed access-control types, and there is no basis here for presenting such a list as a definition of CAS.

A useful mental model is:

• Authentication: identify the actor.
• Authorization: decide what that actor may do.
• Access control: the wider system of rules that enforces those decisions.
• CAS: an older .NET Framework mechanism that evaluated the code itself when deciding permissions.

These ideas can work together. A user may be authenticated, an application may authorize the user, and the operating system may still control whether the process can access a file. CAS belonged to that larger set of security controls, but it addressed a specific part of the problem.

Code Access Security in .NET Framework versus modern .NET

This is the version detail that matters most.

The CAS infrastructure exists in .NET Framework 2.x through 4.x. It is considered unsupported legacy technology.

That means CAS should be understood mainly as part of older .NET Framework applications and documentation. It should not be assumed to be the security model used by .NET 6 or later.

Newer .NET and .NET Core versions removed or changed the old CAS model. As a result, code written with the expectation that the CLR will enforce the old CAS permission system may not behave the same way on modern .NET.

This distinction prevents a common mistake:

> Seeing the words “.NET security” and assuming that old CAS rules still protect a current .NET application.

They do not provide a safe basis for planning a new application’s security design. A modern application needs security controls that fit its actual runtime, operating system, hosting model, identity system, and resource permissions.

That does not make .NET 6 or later a security risk by itself. The supplied facts do not support that claim. They support a narrower point: the old CAS infrastructure is legacy, and newer .NET versions removed or changed it.

If you maintain an older .NET Framework application, CAS may still appear in its configuration, libraries, or documentation. If you are moving that application to modern .NET, treat CAS behavior as a migration concern rather than assuming it will carry over unchanged.

What developers should understand about obsolete CAS APIs

Older CAS APIs can still appear in code examples and inherited projects. Some are described as obsolete, and the underlying CAS infrastructure is unsupported legacy technology.

The practical lessons are straightforward:

• Don’t add CAS APIs to a new modern .NET application as your main security control.
• Don’t assume a permission demand from an old example provides the same protection on current .NET.
• Check the target framework before relying on any CAS-related type, configuration setting, or behavior.
• Separate code trust from user authentication and application authorization.
• Use controls that are actually supported by the runtime and platform you deploy.

When reviewing old code, ask what security problem the CAS code was trying to solve. It may have been limiting file access, controlling network use, or restricting a library based on its origin. That goal may still matter, even if the old CAS mechanism no longer applies.

The replacement depends on the problem. You may need operating system permissions, application-level authorization, safer dependency boundaries, or a different process and hosting design. The important point is not to replace one obsolete API with another without understanding the resource being protected.

Before planning an application security model, verify the exact .NET version you target. Treat CAS as a .NET Framework-era concept, and avoid relying on obsolete CAS APIs as though they were current protections.