Code is very powerful. We can use code to write and read files into the file system of a computer. Code can be used to transfer data over the internet. We can do all sorts of things with coding. It is powerful, but with great power comes great responsibility.
In the 1970s, two access control models were proposed: the identity-centric model and the authorization-centric(capabilities) model.
Identity Centric model and its flaws
The identity-centric model works by assigning permissions to identities such as users. So, when a user is writing some code, the code has all the capabilities the user has. It has all the access and permissions which the user possesses. A simple function you write that sums two numbers has the permissions to access the filesystem on your computer and make network calls. Under normal circumstances, this is fine. But any vulnerabilities can allow an attacker to exploit things. So anything a program can do, an attacker can do as well. This excess authority is the root cause of many security breaches we witness today. The event-stream incident is an example of this, where the event-stream package had a vulnerability, and the malicious code was trying to steal the private key of bitcoin users.
OCAPs and POLA
The authorization-centric model, also known as the capabilities (OCAP) model, addresses these issues by focusing on the principle of least authority (POLA).
In this model, rather than assigning broad permissions to users, specific capabilities are granted only as needed. This means that when a program or a piece of code is executed, it is given only the permissions necessary to perform its function, and no more. This limits the potential damage that can be done if the code is exploited by an attacker.
For example, if you write a function to sum two numbers, under the capabilities model, it would not have access to the filesystem or network unless explicitly granted those capabilities. This minimizes the risk and helps in creating more secure systems.