Upcoming .ROBLOSECURITY Cookie Format Changes

Updates Announcements
1

If you are not using the .ROBLOSECURITY cookie for your own custom use cases, you may ignore this announcement.

Hi Creators,

As we continuously improve the security of the Roblox platform, we will make some breaking format changes to the .ROBLOSECURITY cookie on or after 1 May 2026.

You may be using this cookie in development workflows or as part of live experiences, and we hope that this notice will allow sufficient time to mitigate potential impacts of these changes.

As a recap of cookie behavior:

  • Clients can attach a .ROBLOSECURITY cookie to authenticate their current request
  • Roblox will return a 401 response if the cookie is no longer valid for any reason
  • In some cases, Roblox will indicate to a client via the standard Set-Cookie response header that it should update its stored value of the .ROBLOSECURITY cookie for that cookie to remain valid on subsequent requests

If your use case already respects cookie updates sent by Roblox (via the Set-Cookie response header):

  • This enforcement change should have no impact. All new .ROBLOSECURITY cookies issued by Roblox have incorporated these format changes for several months now

For use cases with an older, hard-coded cookie, and which do not respect cookie updates sent by Roblox:

  • This enforcement change may invalidate their .ROBLOSECURITY cookies, depending on how old any particular cookie is. Clients should upgrade to a recently-minted cookie and respect Set-Cookie response headers to avoid additional breakage going forward (more details below)

As a reminder, Roblox recommends using Open Cloud APIs for your production applications whenever possible, as Open Cloud authentication methods and API contracts provide stability guarantees for third-party use cases and use scoped, secure credentials rather than account-level cookies.

How do I know if I’m using an outdated cookie?

As of this post, outdated .ROBLOSECURITY cookies will have one of two formats:

  • <Cookie Warning><Hex String>
  • <Cookie Warning>GgIQAQ.<Hex String>

Where <Cookie Warning> is the following string:

  • _|WARNING:-DO-NOT-SHARE-THIS.--Sharing-this-will-allow-someone-to-log-in-as-you-and-to-steal-your-ROBUX-and-items.|_

And <Hex String> is a long string consisting only of hex characters (0–9 and A–F).

You can also test your cookie against the following regular expression:

  • ^(_\|WARNING:-DO-NOT-SHARE-THIS\.--Sharing-this-will-allow-someone-to-log-in-as-you-and-to-steal-your-ROBUX-and-items\.\|_)(GgIQAQ\.)?([0-9A-F]+)$

There may be additional outdated cookie formats in the future, and cookie formats may be deprecated without specific notice, so you are strongly urged to accept cookie updates that Roblox sends you using the Set-Cookie header (instructions below).

How can I receive auth cookie updates going forward and future-proof my workflows?

When your .ROBLOSECURITY cookie is eligible for an update, Roblox will respond to your API request normally but may include a standard HTTP response header with the header key Set-Cookie.

This header is sent back on a varying cadence of hours to days (and not on every request), but you will always have a few months to process the header before Roblox begins to reject your outdated auth cookie.

How you access this header depends on the programming language and HTTP client you’re using, but HTTP response headers are typically included in a key-value data structure returned by your HTTP client library. This data structure maps a single header key to one or more header values corresponding to that key.

For auth cookie updates, one of the values corresponding to the Set-Cookie key will look like:

  • .ROBLOSECURITY=<Cookie Value>; <List of Semicolon-Separated Attributes>

You can find more detailed information on cookie attributes here, but the behavior of your client should be to replace your stored cookie value with the new one in the Set-Cookie header (along with its attributes).

If you find that some of your use cases still require cookies, we’d love to hear your feedback.

Please let us know if you have any questions!

76 Likes
2

This topic was automatically opened after 10 minutes.

7

I authenticated a bot a while ago using some bandaid implementation of quick login, this implementation was not programmed to handle Set-Cookie, so I’m wondering exactly what i need to do with my request function.

Do I just overwrite the existing .ROBLOSECURITY entry if a request returns the relevant Set-Cookie header with a new token?

6 Likes
8

it’s so nice to see a company caring about their community!

14 Likes
9

Do you sincerely think community tooling relying on cookies randomly breaking is a good idea because it might, repeat might (probably not, they already have the updated cookies), stop account stealers?

Can we stop pretending like every update is malicious?

38 Likes
10

This reply is so unnecessary. Directing your anger from recent roblox decisions towards engineers is not the way to go.

17 Likes
11

We know that gaps in Open Cloud coverage force many creators to use legacy web APIs and cookies for benign automation use cases. We accept this legitimate usage while we work to improve Open Cloud coverage.

We are respecting those creators’ time here by informing them of these changes upfront, giving them time to adapt so their automation remains stable.

This change does not introduce any new account security risks.

29 Likes
12

Do I just overwrite the existing .ROBLOSECURITY entry if a request returns the relevant Set-Cookie header with a new token?

Exactly right!

8 Likes
13

Thank you roblox developers! For the 2 new good updates!

2 Likes
14

actually that’s a smart update imo. Cuz account stealers will have to update all the cookies once per month or so, but they cant do that from the same device or ip, because it will see “Ok, there are hundreds of cookies coming from a single ip or device” and can mark them as stolen :0

And therefore stealers will have to spend way more money just to change the places where they update accounts from. Tho it will let people with a couple of stolen accounts slip through

1 Like
15

And then like a warning in email on in roblox “Your account might be compromised. Please change your password asap [Reset Your Password Link]” and a danger button “My account is safe, no actions needed”. - to add ip as a whitelist to where it will not say that your account was hacked (it’s like in case if you use service as a developer that requires .ROBLOSECURITY but is processed from a single datacenter)

1 Like
16

In practice when a hack method stops working, hackers notice almost immediately, regardless of whether it’s announced or not

And this isnt some secret or edgy update this is about as basic and boring as it is: cookie format change, proper set cookie handling and the cookie still literally says DO NOT SHARE THIS.

Less drama, more engineering please.

4 Likes
18

Im generally confused. How is this meant to help security?

Cookies are already ip locked, in a sense where if an attacker gets their hands on your cookie and tries to use it on their device it will invalidate logging both people out of the account.

I know the ip locking / device locking cookies is flawed in some cases but it should protect against attackers.

This update seems to break more than it will solve.

Please correct me if im completely misunderstanding.

20

like they haven’t patched that centuries ago anyways

21

Thank you Roblox but you did this VERY late. Should have been done way earlier but it’s better late than never. This would prevent/massively reduce a lot of victims to be beamed/compromised by others including me. Thank you for making an effort to step up security.

22

Good question!

While we can’t share too much about the security changes we have been making to cookies under the hood, the intention of this post is to set the expectation that .ROBLOSECURITY cookies may have breaking updates without specific notice from May 1, 2026 onwards.

Most clients (including the Roblox website, the Roblox apps, and Roblox Studio) will handle these upgrades without any user action required, but we want to make sure that custom use cases can be future-proofed by respecting the Set-Cookie header.

3 Likes
25

I appreciate the continued support for cookie-based requests.

For developers who want an easy way to migrate their old group membership bots, or start their first using Open Cloud, is there any chance you guys could add a short section to the guides page explaining how it works?

Cookie auth for group ranking was one of if not the most common external HTTP use cases before Open Cloud, so having a clear guide to follow would likely help bring those people over.

2 Likes
27

i had no idea there was a new assetdelivery endpoint, this is useful for my use case

20260204_154323s_fZgS28EIQc
20260204_154323s_fZgS28EIQc635Ă—119 9.12 KB

edit 2: it doesnt work
20260204_154725s_eexkd3fmNL

edit 3: i needed to generate a new key with the same perms, idk why an old key didnt work i put the exact same perms
20260204_160304s_5blzaIAEzy

28

Do you still have both keys in your dashboard or did you delete the older key by now? It’d be helpful if you can post a bug report about it if so, so we can take a look separately.

1 Like
29

sorry i changed the old key in frustration :sob:
i didnt delete it but i dont remember what account it was linked to since i made a new account for it

if i find it should i DM you?

edit: i found it in a text file
20260204_164809s_16ClvCzywg