SSR attack vector, and mitigation, when using session from getSession()

[j4w8n]

UPDATE: I've been able to replicate this attack on the client side. This is because an attacker can easily sign up for an account on your app, then tweak their own cookie value to have session.user.id be the victim's user id. Therefore, it's value can't be trusted from a client side getSession() call either - in my opinion. See supabase/auth-js#935

As briefly described on PR supabase/auth-helpers#722, an attacker can retrieve sensitive user data through an attack vector within auth-js and a developer's code. This attack is based on a developer:

• storing user sessions in cookies
• using server-side rendering
• retrieving users' data via information within session.user

In this discussion, I'd like to clarify the topic, from my perspective, and point out some solutions and pitfalls. I welcome your thoughts.

To summarize:

• It is unsafe to call getSession() on the server and then use unique data like session.user.id, to return that user's sensitive information.
• It is safe to call getSession() to retrieve a user's tokens (access, refresh).
• Using non-unique, or non-sensitive, information returned by getSession() is likely safe, but be cautious - e.g. a public url for their avatar, via session.user.user_metadata.avatar_url in the case of a GitHub OAuth login. Just keep in mind that accessing session.user currently throws a console warning.

getSession() vulernability

If we look at how this method works, we see that it runs minimal checks on the potential session it grabs from storage. When I say "minimal checks", I'm not casting any blame; Supabase can't do much more than what it already is.

1. Checks if the session is null.
2. Further validates the session by ensuring that it's of type object, and that it has the properties access_token, refresh_token, and expires_at.
3. Finally, if expires_at is some point in the future, it returns the session to you.

This seems reasonable, but if we craft a cookie with the following values, it would pass all of those checks:

{
  access_token: '',
  refresh_token: '',
  expires_at: '3000000000'
}

Developer code

Say you're server-side rendering a user's page that's been requested. You check that the user is logged-in by calling getSession() - perhaps in middleware. Data from that call comes back to you, so it seems we have an authenticated user for this request. So, now you fetch the user's sensitive data based on the value of session.user.id, then the page contents are returned and rendered in the browser.

It's worth noting that if you're creating a typical Supabase client that's been authenticated with the user's access_token, you're likely not going to fall victim here. This is because any db calls are going to be using that access token against your RLS policies - assuming you use something like auth.uid(). Even if you were to have a request like .eq('user_id', session.user.id), it would fail RLS and no data would be rendered; because the access token's user won't have permissions for any table rows for your victim-user's id.

I'd say the most likely scenario for an attack would be if you're using a "service role" client, or other Supabase client which has elevated db permissions or can bypass RLS (or possibly an RPC call). Because in this scenario, you might craft code similar to:

const { data, error } = await supabaseServiceClient.from('table').select('*').eq('user_id', session.user.id)

In which case...

Attack!

For this attack to work, we need to assume the attacker was able to acquire a victim-user's Supabase user id. It also requires knowledge of the cookie name for user sessions, but this is trivial to find. We also assume the attacker does not have the user's access token or refresh token - otherwise they could just use those to get the victim's data.

Now imagine the attacker sends a page request to the server, using a properly-named cookie with this data:

{
  access_token: 'got',
  refresh_token: 'ya',
  expires_at: '3000000000',
  user: {
    id: '<victim-user-id>'
  }
}

Oh snap! All of the getSession() checks have passed and you've now sent the victim-user's sensitive data back to the attacker.

Mitigation

!!!!!

Only use your JWT secret on the server-side, and only via a private env var. If there are other secure methods, I don't know what they are.

!!!!!

Here are a few things we can do to prevent this attack.

1. Don't use anything from session to render sensitive data. The only exception is verifying and decoding the access_token, with a library such as jsonwebtoken, and then use information within the decoded JWT to load sensitive user data. So, from our example, instead of using session.user.id, grab the value of the sub property from a verified and decoded JWT - which is the user id of whoever the JWT was created for.
2. As the Supabase docs currently recommend: call getUser() to retrieve the user's data and use it to fetch further data for the page. Yes, the getUser call grabs the access_token from getSession and verifies it, but it's worth mentioning that you still can't trust anything else from the session info returned by getSession(). Anyway, if step 1 is not feasible or desired, calling getUser is the easiest solution. The downside is that it requires an extra network request every time you call it - either to Supabase's cloud instance or your self-hosted Supabase instance.

False Security

When I came across this attack vector, my natural solution was to simply call getSession() and verify the JWT, aka session.access_token. I assumed that as long as the JWT checks out, I can use data within session.user to render the page.

However, after thinking about it more, I realized this is a mistake. To understand why, imagine an attacker signs up for an actual account with your app and signs-in. They can then take their legit access token and send a separate request with the below cookie data:

{
  access_token: '<attackers-legit-access-token>',
  refresh_token: 'still got ya',
  expires_at: '3000000000',
  user: {
    id: '<victim-user-id>'
  }
}

As you can see, this would pass the getSession() checks and your JWT verification (access_token), but would still return the victim-user's data. So don't assume everything inside of session can be trusted just because you were able to verify the access_token.

If, instead, we were to grab the legit attacker's token and use the decoded JWT info from it, this would render the attacker's data instead of the would-be victim's. Just take precautions to only use your project's JWT secret, to verify/decode, on the server-side.

[vickkhera]

Nice explanation. I was just looking at some code and I do a setSession() call after validating the token. That would seem to be the right place to make sure the session was replaced with the claims from the token. I need to look to see if that actually happens.

[j4w8n]

Nice explanation. I was just looking at some code and I do a setSession() call after validating the token. That would seem to be the right place to make sure the session was replaced with the claims from the token. I need to look to see if that actually happens.

@vickkhera yes, that would mitigate it as well. setSession calls getUser under-the-hood, and then saves a subset of data to session, including user data from the getUser call. So if it's just the user data you're after, calling getUser() will suffice. But if you're also wanting to essentially authenticate the Supabase client based on the access token, then setSession() is the way to go. Just be aware that with setSession, the saved session will only have the below properties:

/* Reference: https://github.com/supabase/auth-js/blob/master/src/GoTrueClient.ts#L1328-L1334 */
{
  access_token, /* Whatever was passed-in to setSession() */
  refresh_token, /* Whatever was passed-in to setSession() */
  user, /* Based on the getUser() call */
  token_type, /* Always "bearer" */
  expires_at, /* Calculated from the decoded access_token */
  expires_in /* From the decoded access_token */
}

[vickkhera]

Hrm... I was trying to save myself a round-trip to the DB but I guess there's just no way to do that. I'll just change to using the sub properties from the JWT I validated the few places I need it.

[utku-kaan]

[utku-kaan]

@j4w8n I apologize, it's my mistake. I assumed that getSession wouldn't just blindly read from the cookie. I naively assumed that it'd decode the JWT payload and use that to construct the user object instead, but it turns out that it just reads directly from the cookie to save a network request.

Yes, the getUser method is quick and easy.

Sadly, even the getUser() function doesn't protect you from this attack if you use the session returned from getSession. It still returns possibly altered cookie data. Since there's no check, the client can modify the cookie however they want, and it will still blindly return that data both on the server and the client.

At this point, I'd recommend renaming getSession to getSessionFromCookie to make it clear that it's not doing any validation. Thank you for bringing this to my attention. I'll update the post to clarify this point and provide a more secure example.

[j4w8n]

Sadly, even the getUser() function doesn't protect you from this attack if you use the session returned from getSession. It still returns possibly altered cookie data. Since there's no check, the client can modify the cookie however they want, and it will still blindly return that data both on the server and the client.

@utku-kaan you're exactly right here. I just added some verbiage within mitigation 2, to emphasize this.

[jacktsin1]

@j4w8n thanks for the analysis! What if you use .getSession() in combination with RLS as described here?

[j4w8n]

@j4w8n thanks for the analysis! What if you use .getSession() in combination with RLS as described here?

@jacktsin1 I'm not familiar enough with Next to speak on it. But as long as you aren't using info within session.user to render users' data, then this attack isn't relevant.

I've just updated my post, to include some example calls and emphasize that this is more geared towards Supabase clients with elevated db privileges. If someone disagrees, let me know.

[jacktsin1]

@j4w8n Thanks, I suppose the approach I described will do the trick for the majority who don't want to compromise on performance.

In the case I described Nextjs's middleware is just an extra layer of "auth" but the real security functionality basically depends on RLS (not on getUser() or getSession() which are executed in the app — RLS runs directly in your DB when a request reaches it).

If RLS is secure/not vulnerable, then this approach should also be secure.

Either way, if RLS is not in place, I'm not sure if an attacker needs to go through your app to query your DB instance if they have your Public Connection string / Anon key (they are usually publicly available if an app is at least using client-side Auth or Real-Time, not to mention client-side data fetching/mutations).

In fact, even if you have RLS in place, an attacker can still make as many requests as they want to your instance potentially exhausting your bandwidth (given that your connection string and anon key are used client-side), they just won't be able to obtain or alter sensitive information that are being protected by RLS.

So I assume getSession() vs getUser() is just a small portion of the existing vulnerabilities when it comes to how someone could harm your app and data.

And what I mean basically is that if you don't expose your anon key and connection string to the client (which might be a challenge if you need to use Real-Time and client-side Auth), and have RLS in place, it won't really matter if you use getSession() instead of getUser() since your DB and data will be secure either way.

Vice versa, if you expose your anon key and connection string, and don't have RLS in place, then it still won't make much of a difference if you use getUser() or getSession() since the attacker will have to perform a very specific form of attack to get blocked while your DB will be vulnerable to everything else (again, please correct me if I'm wrong at any part).

[hf]

Thank you for this explanation @j4w8n.

The team is actively working on new features within auth-js that makes it easier to verify the JWT (access token) soon. This should alleviate some of the problems with latency if you rely on getUser() for it. Until that's out, proceed with caution on verifying the access token yourselves -- it can be very easy to leak your JWT signing secret. For example, do not:

• Do not put it in environment variables that become public, like those prefixed NEXT_PUBLIC
• Do not put it in a constant, e.g. const myJwtSecret -- this can accidentally end up in your public source code

A leaked JWT secret opens up not only your users under attack (as they can be easily impersonated) but more severely your database (the secret can be used to mint your own JWTs with any role that can bypass RLS).

[GaryAustin1]

This seems like about the same risk as using service_role leaking. Am missing something? The JWT is only used for the API so you can't execute SQL or be a user not assigned to Authenticator. I guess you could isolate a function in one place to reduce the chance of it getting out in wrong kind of client.

[SebasScript]

@j4w8n I have a simple question on this.

Oh snap! All of the getSession() checks have passed and you've now sent the victim-user's sensitive data back to the attacker - not the shown user's id per se, but whatever data you fetched and rendered on the page using that id.

Is this only an issue though if there are "trusted" operations performed server side or server component side?
Means i get information from supabase by using a service role key for example?

If one performs queries for example in a server component and implements @supabase/ssr the mal formed attacker cookie would be passed to the server side supabase instance for example in a middleware in next.js or passed to an edgefunction that generate a server based client with it.

For the middle ware In the old version in of the supabase docs (from a couple weeks ago) this still used
supabase.auth.getSession();
which has now been updated to getUser().

If we stick to the old version

const supabase = createServerClient<Database>(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
  {
    cookies: {
      get(name: string) {
        return request.cookies.get(name)?.value;
      },
      set(name: string, value: string, options: CookieOptions) {
        request.cookies.set({
          name,
          value,
          ...options,
        });
        response = NextResponse.next({
          request: {
            headers: request.headers,
          },
        });
        response.cookies.set({
          name,
          value,
          ...options,
        });
      },
      remove(name: string, options: CookieOptions) {
        request.cookies.set({
          name,
          value: "",
          ...options,
        });
        response = NextResponse.next({
          request: {
            headers: request.headers,
          },
        });
        response.cookies.set({
          name,
          value: "",
          ...options,
        });
      },
    },
  }
);

await supabase.auth.getSession();

return response;
}

in an edge function same by reading the auth header from the request and passing that into the create client

   const authHeader = ctx.request.headers.get("Authorization"); //using oak here to get the auth header
  const supabaseClient = createClient<Database>(
    Deno.env.get("SUPABASE_URL") ?? "",
    Deno.env.get("SUPABASE_ANON_KEY") ?? "",
    {
      auth: {
        persistSession: false,
      },
      global: {
        headers: {
          Authorization: authHeader || "",
        },
      },
    }
  );

this would use the mal formed cookie now and not verify it. But if one now performs a database query with this mal formed supabase client the query should fail on the backend as the backend would try to validate the malformed jwt that is send with the request?

[j4w8n]

@SebasScript, you're typically fine with db queries like the ones you mentioned, because only the access_token is used.

The exception to that is using a Supabase client on the server-side with elevated privileges, like the service_role key that can bypass RLS, and using filters based on data from session.

For example, the below would return a victim-user's data.

/* Received attacker request with this cookie: */
{
  access_token: 'got',
  refresh_token: 'ya',
  expires_at: '3000000000',
  user: {
    id: '<victim-user-id>'
  }
}

const supabaseServiceClient = "code here" /* Construct with `service_role` key. */
const { data: session } = await supabaseServiceClient.auth.getSession()

const { data, error} = await supabaseServiceClient.from('table').select('*').eq('user_id', session.user.id)

[chanon]

Can I ask, other than sub, which I assume is the user's uuid, what other data can be guaranteed to be available in the decoded access_token JWT ?

[j4w8n]

Here is a cleaned version of a decoded JWT, when logging in with GitHub. Yes, sub is the user's ID.

{
  aud: 'authenticated',
  exp: 1714645059,
  iat: 1714644819,
  iss: 'https://<project-id>.supabase.co/auth/v1',
  sub: '00000000-0000-0000-0000-000000000000',
  email: '[email protected]',
  phone: '',
  app_metadata: { provider: 'github', providers: [ 'github' ] },
  user_metadata: {
    avatar_url: 'https://avatars-r-us.com/u/42',
    email: '[email protected]',
    email_verified: true,
    full_name: 'Forty Two',
    iss: 'https://api.github.com',
    name: 'Forty Two',
    phone_verified: false,
    preferred_username: 'fortytwo',
    provider_id: '25783093',
    provider_token: '',
    sub: '00000000',
    user_name: 'fortytwo'
  },
  role: 'authenticated',
  aal: 'aal1',
  amr: [ { method: 'oauth', timestamp: 1714643412 } ],
  session_id: '11111111-1111-1111-1111-111111111111',
  is_anonymous: false
}

[godlin-gh]

I am trying to build my app with Next.js and Supabase Auth following this doc: https://supabase.com/docs/guides/auth/server-side/nextjs

Now the doc says we should use getUser() in the Next.js middleware, and it sends a request to the Supabase Auth server every time to revalidate the Auth token.

But The Next.js middleware runs on edge runtime, which is close to end users but may be farway from Supabase Auth server

Then, the getUser() may experience significant latency depending on the user's location.

In my case, the latency is more than 500ms，from HongKong to the US.

Middleware is not designed for direct data fetching or manipulation, this should be done within Route Handlers or server-side utilities instead. https://nextjs.org/docs/pages/building-your-application/routing/middleware#use-cases

I hope you guys can solve this problem as soon as possible, may be you can issue a signed idToken and read user profile from it.

[CesGalaxy]

I hope this helps someone:

My app was very slow with the middleware and I managed to fix it by creating an API route that calls the getUser() method, then at the root layout I wrapped all the pages with a client component that called that API route (I think you could make it run just once a day, so it doesn't call the API without reason) and the cookies get updated after refreshing the user token.

Sorry for my bad english :P

[bbozzay]

I implemented the new getSafeSession changes in my project and had no indication locally that there would be a massive spike in redundant auth requests caused by this. Once I deployed, I eventually noticed a huge spike and thought I was getting DDoS'd...

I immediately jumped from <100 auth requests per hour to around 1-3k per hour.

My project uses Sveltekit, but I noticed @Zanzofily next.js safesession package created to address the performance problems as well. He notes that one user generated 1,685 calls.

I implemented this change based on the official docs. I imagine this issue is widespread, but I'm still seeing stale Git issues from back in March. I created a reddit thread for more visibility. Now I'm scrambling to implement the changes based on your sveltekit-supabase-ssr project.

[Zanzofily]

I implemented the new getSafeSession changes in my project and had no indication locally that there would be a massive spike in redundant auth requests caused by this. Once I deployed, I eventually noticed a huge spike and thought I was getting DDoS'd...

I immediately jumped from <100 auth requests per hour to around 1-3k per hour.

My project uses Sveltekit, but I noticed @Zanzofily next.js safesession package created to address the performance problems as well. He notes that one user generated 1,685 calls.

I implemented this change based on the official docs. I imagine this issue is widespread, but I'm still seeing stale Git issues from back in March. I created a reddit thread for more visibility. Now I'm scrambling to implement the changes based on your sveltekit-supabase-ssr project.

Fixing this issue is relatively simple. A single solution can be applied to the TuroAuthClient and would serve all frameworks.

I believe the reason this might be taking a while is the uncertainty that everyone would follow best practices (validate session using database on the middleware or every now and then, using the right database constraints on user_id, and preventing insertions/updates from a deleted user)

If you implement the solution in my or @j4w8n repo, make sure you keep an eye open for these cases.

[DawidWraga]

Thank you for highlighting this issue

This is a very important and urgent problem that Supabase team must prioritise to keep the trust of developers

I really hope to see the Supabase team addressing this quickly otherwise I feel forced to consider alternatives, which I really don't want to do

[Aradon267]

Amazing article!
Is it fine to use the "data" from getSession(data=wether or no I received something) only to know if the user is connected and to do all the other things that are related to data fetching(like getting the user id to get its data from the DB) using the getUser?

Edit:
The basic code that I mean to see if the user is logged in is

//supabase middleware creation

const { data: activatedUser, error } = await supabase.auth.getSession();
    return NextResponse.rewrite(new URL("/login", request.url));
  }

  return response;

While any other request I make using the user's actual data(i.e. the user's ID) is always received using getUser

Also due to the getSession that is used(although no data is used to fetch anything) - I get the log that it's unsafe to use that which is fair as it is but calling getUser for each server action that is used in the client(they all go through my middleware) seems extensive as I also have RLS setup and most of the time for me calling getUser causes rate limits

[Aradon267]

And would that still be the case if it's combined with the first mitigation proposed?

[j4w8n]

No, that's not the case if you're doing mitigation number 1. You'd be good to go as long as you're checking event.locals.getSession and not supabase.auth.getSession

[Aradon267]

And is there a reason for any method to not work in either place? I can understand why the first is bad on the client because I don't want to leak the JWT but is there a reason for the getUser to not work on the server side(just something that I only now started dealing with as it says there's no session)?

[j4w8n]

And is there a reason for any method to not work in either place? I can understand why the first is bad on the client because I don't want to leak the JWT but is there a reason for the getUser to not work on the server side(just something that I only now started dealing with as it says there's no session)?

You might be dealing with a different issue in that case, because getUser works on client side and server side.

[Aradon267]

Yeah that worked for a long time, will try to see the problem
Thanks!

[kvetoslavnovak]

It looks like JWT Secret usage may be quite sensitice. It i is shame to need to use another secrete and take care of it.

[j4w8n]

It looks like JWT Secret usage may be quite sensitice. It i is shame to need to use another secrete and take care of it.

When they release asymmetric jwts, this won't be as big of a deal. No timeline on that, but I believe they're working on it.

[hf]

We want to have this released in the next 2 months, and it's first priority for the team.

[jonafll]

@hf Any news about that?

[anarkrypto]

I created a safe workaround to verify from JWT using Supabase JWT Secret.
It's compatible with the edge runtime.

Source: https://gist.github.com/anarkrypto/9ee98bd23f25efd44a4cfb4ed256837a

Usage:

const safeSession = new SupabaseSafeSession(supabaseInstance, jwtSecret)
const { data, error } = await safeSession.getUser()
if (error) throw new Error(error.message)
console.log("user data":, data)

Result:

{
  "id": "12345678-90ab-cdef-1234-567890abcdef",
  "session_id": "fedcba98-7654-3210-fedc-ba9876543210",
  "role": "authenticated",
  "email": "[email protected]",
  "phone": "",
  "app_metadata": { "provider": "email", "providers": ["email"] },
  "user_metadata": {
    "email": "[email protected]",
    "email_verified": false,
    "phone_verified": false,
    "sub": "12345678-90ab-cdef-1234-567890abcdef"
  }
}

[DawidWraga]

@hf or someone from the Supabase team I'd really appreciate it if you could please could you review this and let us know whether it's a safe mine-while workaround

Thanks

[anarkrypto]

@DawidWraga the code is simple to understand, I'm just getting the access_token from supabase.auth.getSession itself and then decoding the user data directly from the Supabase JWT with the jose lib.

[DawidWraga]

@anarkrypto That's true I see what you mean. The code is simple and clear.

I'm hopeful that this works but I think it's healthy to be cautious since it's such an important thing to get right. I'd appreciate to hear whether you have thoroughly this solution or if there are any limitations.

It confuses me why the Supabase team didn't release a similar fix a long time ago, and mentioned it would take 2 months to fix

So I'm curious to hear others perspective on this to better understand the situation

[j4w8n]

@anarkrypto That's true I see what you mean. The code is simple and clear.

I'm hopeful that this works but I think it's healthy to be cautious since it's such an important thing to get right. I'd appreciate to hear whether you have thoroughly this solution or if there are any limitations.

It confuses me why the Supabase team didn't release a similar fix a long time ago, and mentioned it would take 2 months to fix

So I'm curious to hear others perspective on this to better understand the situation

@DawidWraga, the Supabase team does not want to recommend a solution that involves devs using their jwt secret. They say it's easy to accidentally leak it to client side code if someone isn't careful.

If you have doubts about using it, use getUser until the team releases a safer alternative.

[gc-ft]

A few questions to check my sanity, since some how this sounds "worse" than it actually is.

1. The attack vector is against using session.user not the jwt token itself that comes from getSession() and is used in Auth headers to PostgREST. Meaning, it can be used against someone who believes that raw unverified data in session would somehow be ok to use in queries without RLS and displaying or even manipulating data based on those. Yes, a user could also "fake" to be logged in, however no data would ever be leaked to this malicious user because not a single request to the actual database would ever result in ANYTHING as long as RLS is used.
2. Furthermore, if you do not use RLS, but use the getUser() data in queries, unless they run 100% on the server and none of it is exposed on the client, and there is no way to manipulate the postgREST query variables, getUser() is not really any safer. The safety here comes clearly from RLS! Yes, it would be nice to depend on the decoded data in getSession(), however I do not really see an attack vector here in connection with RLS?
3. Which brings me to my most important point: The "attack vector" has nothing to do with SSR or not, is that correct? The reason this warning was placed in the code was so people using session.user on the server do not feel safe and simply drop RLS and use service_role keys since it was "quicker".

The expectation by whoever added the warning was that it should be CRYSTAL CLEAR that using service_role keys on the client side and circumventing RLS is a recipe for disaster.

Or is there some specific safety on the client that makes this "ok" there that I simply can not see?

So, again, this attack vector exists only in connection with using RLS-circumventing-queries anywhere, client or server side, or displaying data from some non-supabase source based on the session.user data.

Actually, if you never USE for example the user uuid anywhere, or some special metadata from the JWT to unlock features which interact with places outside of supabase, and use RLS in supabase, there is no need to run getUser() on every request since any interaction with supabase will also return an authentication error of some sort if the data was compromised or faked, or the site will simply not work with compromised or faked data.

Of course I am very much looking forward to asymmetric JWTs being implemented (and btw, they are implemented in supabase/auth for a couple of weeks now, thanks km (if I remember correctly)..., I am guessing work is being done on the UI and the other libraries to support it as we speak), simply because it is nice to be able to authenticate the JWT safely anywhere, including on the client, and knowing one can depend on the data inside the JWT just like one could on server-stored session data back in the old days, prior to JWTs and client side javascript trickeries.

But, in no way are we forced to depend on the data today, OR are we forced to run getUser() on every single interaction with our system, as long as RLS is used the way it should be.

Just wanted to put this into perspective and make sure I am not missing something...

[j4w8n]

To quote myself, from the initial post:

It's worth noting that if you're creating a typical Supabase client that's been authenticated with the user's access_token, you're likely not going to fall victim here. This is because any db calls are going to be using that access token against your RLS policies - assuming you use something like auth.uid(). Even if you were to have a request like .eq('user_id', session.user.id), it would fail RLS and no data would be rendered; because the access token's user won't have permissions for any table rows for your victim-user's id.

I'd say the most likely scenario for an attack would be if you're using a "service role" client, or other Supabase client which has elevated db permissions or can bypass RLS (or possibly an RPC call).

[alexnguyen98]

Any news on this?

[andreasvirkus]

It'd be great to know if there's a timeline or plan in place for this at least 🙏 We'd want reassurance that this is a priority.