Introducing Plugin HTTP Permissions

Hey Developers,

As games get more intricate and many of you rely more and more on different plugins and tools, we want to make sure that you are able to do so in a safe manner. Content security is our #1 priority as we look to scale the Developer Marketplace so all of you can be confident that assets found there will only perform actions that you are aware of.

To that end, we are excited to announce our first iteration of plugin permissions: granular HTTP permissions. Now, whenever a plugin makes a web request to a new domain, you will see a pop-up dialog requesting you to approve or deny access to the plugin for that domain, or cancel the individual request. These permissions will be persisted across sessions and are configurable via the Plugin Management page at any time! HTTP permissions will be requested every time any plugin makes a new request from any domain that it has not previously made a request to.


A few things to note:

  • Accepting or rejecting the domain from the dialog will remember your preference for the given plugin and domain.
  • Closing the dialog without making a decision will reject the current request without remembering your preference.
  • All previously existing Studio plugins will now use the new model and ignore the game’s Allow HTTP Requests setting - that setting now applies only in game, and if you are not making HttpService requests from your game, you can safely turn off that feature without losing plugin functionality from popular plugins.
  • Local plugins will bypass permissions.
  • This feature will ask for request on a per-domain basis. All sub-domains will need to be granted explicit permission.

This is just the tip of the iceberg for content security. Our team is working hard on the next set of permissions to help mitigate some of the major weaknesses reported by all of you including preventing unauthorized game teleports and script injections.

A big shoutout to our team for making this happen: @Mr_Purrsalot, @applepinecake, @iriszh, @St4rst0n3, @portenio, @Seranok, and @longlongchien!


This is perfect for stopping HTTP vulnerabilities in Studio, thanks! I’ve wanted to control this for ages.

edit: there was a question here, but it was already answered implicitly in the OP.

New question: is HttpService.HttpEnabled now true for all plugin contexts? (plugin scripts, modules required in plugins, etc)

Do these plugin scripts now run in a completely separate environment from in-game scripts?


Thank you for finally doing this.

There was a huge loop-hole I had found about a year ago, that could have plugins get the user’s IP address and post it to a server. I emailed Roblox about this several times, and they fixed it.

^^ The reason that worked is Roblox Studio is connected to the user’s local IP address, which is not the biggest deal but it is a infiltration of user privacy ( not connecting studio to the user’s IP, stealing an IP address is an infiltration of privacy and dangerous ), so that meant plugins can post a get HTTP request from a user’s local IP address and then post a request to a server with the user’s IP address, and boom, it was stolen.

I am legitimately so happy Roblox finally fixed this, now I feel a lot safer using plugins.

This will upgrade user’s safety. Thank you!


Hopefully this is opening the gate for other plugin permissions, such as preventing plugins from using require if we don’t explicitly allow it. Cough, backdoors. Remove require from the executing environment if we don’t allow it, wham, no one’s requiring modules if we don’t allow it.

Might be problematic for legitimate plugins using require but it’s still good to be informed that the plugin is using require at all and what exactly they’re requiring (either an outside asset or something within the plugin) so that we can decide whether or not the plugin should be allowed to continue.


Great to see this feature finally coming into play. This will increase users safety while using plugins, rather than their personal information getting exposed. Along with preventing plugins that have backdoors in them, which there is a ton of, overall I’m glad this feature is out now.


Will this dialog box show the entire URL or just the main domain?


Wow! This will be making a big change to the plugin industry! I think this is needed and I appreciate this update.

I’d instead make it fail for asset IDs, rather than removing require entirely - remember that requiring module instances is a thing. My plugins depend on that (for non-injection purposes)!

edit: for context:


Modules (and implicitly, the ability to use them) are critical to my coding best practices. If I lost the ability to manage my code using them, I’d be pretty tempted to just stop making plugins until a reasonable alternative came along. Maintenance would be a nightmare.


Added that to the bottom. Thing is though that it’s a slippery slope so I’d prefer rejecting unauthorised requires altogether. Exploiters can adapt by simply integrating the module within the plugin itself instead of making it an outside require. Easier for us to vet infected code but they can bypass the id restriction.


When you say ‘local plugins will bypass permissions’, does that mean that plugins put into %localappdata%/Roblox/Plugins will just be able to send HTTP requests without any restrictions even with HttpEnabled set to false?

If so, I like where this is going. Plugins installed on the file system should always have had enhanced permissions, and if that trend continues I’ll be happy.


So if I’m correct this solves security issues with HTTP?

I don’t really see how it would be a slippery slope - as long as the restrictions are transitive (i.e. modules required in a given context are subject to the same limitations as the calling context), then there’s no risk at all. It’s like running code from a function, except the source code is in a different local container.

Anyway, this is a bit off topic, so we should move somewhere else. New thread time?

1 Like

This is awsome,but i just thought of a thing,what if that HTTP Request, is constantly requesting,resulting in the player not being able to edit the game?Or there will be something to stop that/that wont happen?


This can still be done by creating another script to do it, as GetAsync is not plugin only.

This can be done in-studio, but cannot be done in-game. If you’re doing this in-game, you are basically stealing the game’s IP address ( server where everyone is connected to ). If you do this in team create, it will simply just post the server IP that everyone is connected to. if you do this on your own , you’re stealing your own IP. So yes, this privacy concern has been patched by Roblox. Previously, anyone could make a plugin and steal a different user’s IP address. That was a way bigger concern than now.

1 Like

Finally, I needed this. Many of my private plugins rely on endpoints to retrieve data.

Thanks for adding this.

This is great and I’ve wanted this for ages, thanks for adding this!

Can’t wait to see more granular plugin permissions. Another big few ones for me are preventing plugins from reading/writing to datastores, modifying Source property of scripts and modules, and inserting other persistent objects/properties into the DataModel, although for that last one I’m not entirely sure what would be the most elegant way to prevent that.


Of course, it is studio only problem, but what I was saying you can make the plugin create another script hidden somewhere to do the HTTP Get to still receive the users IP once he playtests the game in studio. This change has only limited getting the user’s IP address upon opening the studio.

This is definitely a step in the right direction but a lot of these malicious plugins install scripts into the game that only make those HTTP requests in a live game server outside of roblox studio’s control. I’ve also seen some that use TeleportService and teleportData and make the requests in a game outside of the user’s control. Maybe some sort of plugin permissions thing such as what mobile apps have currently is due? For example, “this plugin needs X permission to do X thing”.


Haven’t tried this yet. I will take some steps and test this to the fullest. Thanks for informing me about this.

I do however believe Roblox most likely took precautions to prevent this from happening. But, only way to know is to see.

1 Like