Deno is a Javascript runtime like NodeJS and it has a new security feature that you need to know about. We all love Deno’s allow permissions but this month they released a new deny permissions API that might change how you write your applications and run scripts. Check out the video, have a play and let me know in the comments what you think. Will you keep using Allow permissions? Does Deny permissions change how you write your applications? You can read all about Deno’s new permissions API in the 1.36 release notes https://deno.com/blog/v1.36
Deno has released a new version and it contains a security feature that you need to know about.
If you have used Deno before you have encountered the permissions flags that give you the ability to allow access to certain APIs in your script. This means you can allow list features like reading from the file system or making network requests.
This is an important feature since Deno’s secure by default nature means your code has access to nothing. No network requests, no file system permissions and no ability to run other scripts.
As software engineers in the modern world we want and need a secure by default runtime for our code to prevent hackers using language features we would otherwise prevent.
Deno’s permission functionality becomes even more important when running code from other engineers that we can’t always trust. If you download a Deno script from the internet you can explicitly allow permissions and be sure that the script is not sending your passwords off to another server.
Allow permissions are great but it has limitations. If you have a script that reads different files from your machine you need to give permissions to each folder or file that you want it to access. This is very secure but can be cumbersome.
As of Deno 1.36 released on the 10th of August 2023 developers now have access to Deny Permissions. These deny permissions work in the exact opposite way to allow permissions.
Using Deny permissions means we can add a list of environment variables we DO NOT want the script to access for example an AWS key used by your build pipeline. In the allow permissions style you would need to allow-list each individual environment variable you want the script to access but now we can deny-list specific values.
There is a risk with this though. When using an allow list it is on the person running the code to choose each specific permission and parameter given to the script. When using the deny list format it’s possible to allow network requests and deny some malicious domains but not all of them. In the case where you are only calling out to a single domain, for example a backend API, it is still better to use the allow list format.
Something else to keep in mind is if the script you are using logs the flags it is called with when being run. You might inadvertently give your secret folders and file names away to a developer when you send through the deny list of permissions.
I always find the best way to learn is through experience so let’s take a quick look at these permissions in action.
I have a simple script that reads the file hello.txt from the file system. When I run this script with no permissions there is a warning that the script requires permissions I have not granted. If I select no then my script will fail as it is unable to read the file.
Next I run the script with the allow read flag and the contents of my text file are shown in the terminal. I can use the more explicit allow read flag with the file name and get the same result.
Now I edit the script and try to access the passwords.txt file, when I provide the allow-read permission I give access to this file even though I want to keep it private!
Let’s use the new deny permissions to solve this. When running the script I add deny-read equals password.txt, now when my script runs I see it trying to read my passwords and I can deny that action.
You can see that the allow and deny permissions provide similar functionality but in different ways, giving more flexibility to the scripts that we write and run.
Overall I think this is a good feature and release from the Deno team that provides more flexibility to people using the Deno runtime for their Javascript projects.
You can read about these new permissions over at the Deno blog and release notes for version 1.36 which I have added to the video description below.
