Supabase를 사용하다 보면 Row Level Security(RLS)를 켜놓은 상태에서 UPDATE 쿼리를 실행했는데도 다음과 같은 에러를 만날 수 있습니다:
ERROR: permission denied for table user_profiles
“분명히 Policy도 설정했는데 왜 안 되지?” 싶은 분들을 위해, 이 글에서는 이 에러의 근본 원인과 해결 방법을 예제로 함께 정리합니다.
🧩 문제 상황
🔁 시도한 쿼리
update public.user_profiles
set name = '테스트'
where id = 'e0804eda-xxxxx-xxxxx-xxxxxx-xxxx';
⚠️ 발생한 에러 로그
ERROR: permission denied for table user_profiles
이 에러는 단순히 RLS 정책이 없어서가 아닙니다. 오히려 RLS는 잘 설정되어 있었지만, PostgreSQL 권한(GRANT) 자체가 누락되어 있어서 발생하는 것입니다.
🔍 원인 분석: Supabase의 보안 구조
Supabase는 다음 두 단계를 거쳐 요청을 허용합니다:
✅ 1. PostgreSQL 권한 (GRANT)
•역할(Role)이 테이블에 접근할 수 있는지
•예: SELECT, INSERT, UPDATE, DELETE 권한을 가졌는가?
✅ 2. Row Level Security (RLS) 정책
•해당 row에 접근 가능한 조건을 만족하는가?
•예: 로그인한 사용자의 auth.uid()와 row의 id가 일치하는가?
즉, GRANT + RLS 둘 다 통과해야 UPDATE가 작동합니다.
🛠️ 해결 방법
1️⃣ 테이블 권한 부여
GRANT UPDATE ON public.user_profiles TO authenticated;
필요에 따라 SELECT도 함께 부여합니다:
GRANT SELECT ON public.user_profiles TO authenticated;
2️⃣ RLS 활성화
ALTER TABLE public.user_profiles ENABLE ROW LEVEL SECURITY;
3️⃣ RLS 정책 작성
로그인한 사용자가 자신의 프로필만 수정 가능하게 만들기:
CREATE POLICY "Users can update their own profile"
ON public.user_profiles
FOR UPDATE
TO authenticated
USING (auth.uid() = id)
WITH CHECK (auth.uid() = id);
•USING: 해당 row를 조회할 수 있는 조건
•WITH CHECK: 해당 row를 수정할 수 있는 조건
✅ 최종 정리
설정항목
설명
예시
GRANT
테이블에 대한 접근 권한 부여
GRANT UPDATE ON ... TO authenticated
RLS ENABLE
Row-Level Security 사용 설정
ALTER TABLE ... ENABLE ROW LEVEL SECURITY
POLICY
행(row) 단위 조건 설정
USING, WITH CHECK 조건 작성
🧪 결과: 정상 동작
위 설정이 완료되면, Supabase Auth를 통해 로그인한 사용자가 자신의 id를 가진 row에 대해 다음과 같은 쿼리를 정상적으로 실행할 수 있습니다.
update public.user_profiles
set name = '테스트'
where id = '로그인한_사용자의_id';
✍️ 마무리
처음엔 "RLS 정책만 설정하면 된다"고 생각하기 쉽지만, Supabase는 PostgreSQL 위에서 작동하는 만큼 기본 권한 설정도 꼭 필요합니다. 앞으로는 permission denied 에러가 나면 다음 두 가지를 먼저 체크해보세요:
import codecs
import json
import osm2geojson
# 각 feature에 bbox 추가
def add_bbox_to_features(geojson):
for feature in geojson['features']:
geom = feature.get('geometry')
if not geom:
continue
coords = geom.get('coordinates')
def extract_coords(c):
if isinstance(c[0], (float, int)): # Point
yield c
else:
for sub in c:
yield from extract_coords(sub)
min_lat = min_lon = float('inf')
max_lat = max_lon = float('-inf')
for lon, lat in extract_coords(coords):
min_lon = min(min_lon, lon)
min_lat = min(min_lat, lat)
max_lon = max(max_lon, lon)
max_lat = max(max_lat, lat)
feature['bbox'] = [min_lon, min_lat, max_lon, max_lat]
# OSM 파일 읽기 및 변환
with codecs.open('sample.osm', 'r', encoding='utf-8') as data:
xml = data.read()
geojson = osm2geojson.xml2geojson(xml, filter_used_refs=False, log_level='INFO')
# feature 단위 bbox 추가
add_bbox_to_features(geojson)
# 저장
with open("result.json", "w", encoding="utf-8") as f:
json.dump(geojson, f, ensure_ascii=False, indent=2)
osm2geojson이라는 python package가 있는데 이를 활용하여 간단하게 만들수 있습니다.
(bbox는 사실 필요 없는데, 저는 bbox 활용할 일이 있어서 추가 작성 했습니다.)
osm2geojson 예제에 text encoding 관련된 부분에 한글이 고려 안되어있는 부분이 있습니다. 그래서 unicode 텍스트 (이거 뭐랄까 ascii로 unicode를 하나하나 출력) 출력되는데, 이부분 주의가 필요합니다.
with open("result.json", "w", encoding="utf-8") as f: json.dump(geojson, f, ensure_ascii=False, indent=2)
Supabase 본격적으로 사용하다보면, RLS를 접하게 되는데요. 이 RLS 개념이 상당히 편리한 기능입니다.
Row Level Security , 즉 DB 의 특정 필드의 값을 채크하여 query 시 Row 단위로 제외 시킬 수 있는 방식입니다.
id
user_id
created_at
title
content
team_id
1
mika
11
안녕하세요.
개발 진행 합니다.
1
2
other
12
개발 의뢰 합니다
이런거 개발해 주세요.
2
말로 표현하려니 좀 어려웠는데요.
위와 같은 table이 있다고 한다면, user_id 가 mika. 인 데이터만 가져오려고 한다면,
query시 user_id 가 mika 인 조건을 추가해서 client에서 호출하면 됩니다.
그러나, 만약 클라이언트 개발자가 이 과정에서 특정 경우에 조건을 추가하지 않았다면, 다른 사람의 정보들까지 노출되버리겠죠.
이를 시스템 상으로 보완할수 있는 하나의 방법이 RLS 입니다.
RLS에 기본적인 예제로 acceess token에서 auth 정보를 가져와서 접근 권한을 설정할 수 있기 때문에, 로그인한 사용자에게 맞춰서 데이터를 필터링 할 수 있게 됩니다.
문제는 뷰 (View)
View 는 기본적으로 RLS가 적용 안됩니다.
VIEW로 쿼리할때 데이터가 필터링 안되는지 몇시간 고민하다 찾게 된 사항입니다.
만약 View를 만들어서 사용하려면, View를 만들때 RLS가 적용되도록 해야합니다.
WITH ( security_invoker = TRUE )
view 생성시 이렇게 security_invoker를 설정해주면 RLS가 적용됩니다.
create or replace view
[view이름] WITH ( security_invoker = TRUE ) as
select * form [talbe이름]
아래와 같은 형식이 되겠죠..
create or replace view
public.myview WITH ( security_invoker = TRUE ) as
select
mydata.*
user_profiles.name as user_name,
user_profiles.email as user_email,
org.name as org_name,
sites.name as site_name
from
mydata
left join user_profiles on mydata.user_id = user_profiles.id
left join org on mydata.org_id = org.id
...
ALTER를 이용하여 기존의 View에 적용하는 방법.
View는 RLS 를 설정 할 수 없습니다. 이걸로 좌절하고 주말을 보냈는데, 찾다보니 방법이 있더군요.
ALTER VIEW my_view SET (security_invoker = on);
이렇게 설정을 하면 my_view 에서 query하는 table에 RLS가 적용 됩니다.
다만 이렇게 했을때 문제는 my_view 가 접근하는 모든 table에 RLS가 잘 적용 되어있어야 동작 한다는 것입니다.
a table은 접근 권한이 있고 b table은 접근 권한이 없으면 퍼미션 에러가 발생합니다.
View 뿐만 아니라, Table 에서도 마찬가지 입니다.
(이건 시스템을 어떻게 설계하느냐의 문제이기 때문에 이런 부분 고려해서 설계하면 좋겠네요)
supabase의 token에 "access", "org_depart_id", "org_id" 를 추가한 형태입니다.
그럼 절차를 확인 해보도록 하시죠.
DB의 policies 를 살펴보면, 사용자에 따라 접근권한을 설정할때, auth.uid() 같은 함수를 이용해서 현 사용자만 접근 가능하도록 할 수 있죠.
그런데 만약 같은 팀원만 볼수 있게 하고 싶다면, 음.. 일단 RLS에서 team에 대한 table join 해서 팀에 소속되어있는지 확인해야 합니다.
(예제에도 그렇게 되어있죠)
그런데 table join이 들어간 코드와 아닌코드의 성능 차이기 약 99% 차이가 난다고 예제에 나와있어요.
table join이 빠지면 99% 성능 향상 ..
그런데 만약 auth token에 추가정보를 담고, RLS에서 auth token에 있는 정보를 활용해서 필터링 할 수 있다고 한다면, (지금 시도해보고 있음), ㅅa
table join없이 처리가 가능합니다. 즉 향상된 성능으로 처리할 수 있다는 것이죠.
0. custom_jwt_token_hook 추가하기
supabase 에서 auth hook을 추가합니다.
Authentication -> Hooks 를 선택 -> Add Hook
이런 화면이 나오죠.
- DB는 postgres 선택하고, schema를 선택해야 하는데 이때 public으로 해도 되지만, 저는 따로 private schema를 만들어두어서 그걸 이용했습니다. (public은 expose되어있어서 불안한 부분이 있거든요)
- 그리고 function을 선택해야 합니다. (지금 구현된 것이 없기 때문에 만들어야 겠죠).
custom_jwt_token_hook 구현
private schema 를 만들어서 추가 (public schema는노출 되어있기 때문에 피하는 것이 좋다. )
javascript 가 plpgsql보다 익숙하여 plv8 import하여 javacript로 작성하였습니다.
//함수 명: custom_jwt_token_hook
var org_id, access, org_depart_id;
// -- Fetch the current user's level from the profiles table
var result = plv8.execute("select id, org_id, access, org_depart_id from public.user_profiles where id = $1", [event.user_id]);
if (result.length > 0) {
org_id = result[0].org_id;
org_depart_id = result[0].org_depart_id;
access = result[0].access;
} else {
org_id = 0;
org_depart_id = 0;
access = '';
}
// -- Check if 'claims' exists in the event object; if not, initialize it
if (!event.claims) {
event.claims = {};
}
// -- Update the level in the claims
event.claims.org_id = org_id;
event.claims.org_depart_id = org_depart_id;
event.claims.access = access;
return event;
- user_profiles table을 만들고 이 테이블에 org_id, org_depart_id를 담고 있다.
SQL Editor에서 작성하는것이 더 편리합니다.
create or replace function custom_jwt_token_hook(event jsonb)
returns jsonb
language plv8
as $$
var org_id, role, org_depart_id;
// -- Fetch the current user's level from the profiles table
var result = plv8.execute("select org_id, role, org_depart_id from public.user_profiles where user_id = $1", [event.user_id]);
if (result.length > 0) {
org_id = result[0].org_id;
org_depart_id = result[0].org_depart_id;
role = result[0].role;
} else {
org_id = 0;
org_depart_id = 0;
role = '';
}
// -- Check if 'claims' exists in the event object; if not, initialize it
if (!event.claims) {
event.claims = {};
}
// -- Update the level in the claims
event.claims.org_id = org_id;
event.claims.org_depart_id = org_depart_id;
event.claims.role = role;
return event;
$$;
grant all
on table public.user_profiles
to supabase_auth_admin;
revoke all
on table public.user_profiles
from authenticated, anon, public;
1. custom jwt를 통해서 token에 추가정보가 들어간것 확인했습니다.
=> 정상적으로 설정이 완료 되면 token에 정보가 들어간 것을 볼 수 있다.
주의 점은 user_profiles에 접근 권한이 설정 되어있어야 한다는 것입니다.
supabase 의 auth 로직은 supabase_auth_admin role로 동작하기 때문에, user_profiles 의 select에 authenticated, supabase_auth_admin role이 필요합니다.
2. 서버에서 RLS 로직에서 추가정보를 꺼내올 수 있는지 확인 필요.
=> 확인 중인 사항 (확인 완료!)
아래처럼 org_id 값을 비교하고 싶을때, org_id가 int8 (숫자)인경우라면, 숫자를 문자로 변경해서 비교 해야함.
ALTER POLICY "Enable read access for same org"
ON "public"."devices"
TO authenticated
USING (
(auth.jwt() ->> 'org_id')::text = org_id::text
);
3.테스트를 위해서 local pc에서 custom jwt 를 테스트 해 볼 수 있는 환경 구축..
가이드에 이렇게 적혀있음
# This hook runs before a token is issued and allows you to add additional claims based on the authentication method used.
# [auth.hook.custom_access_token]
# enabled = true
# uri = "pg-functions://<database>/<schema>/<hook_name>"
config.toml 에 다음 과 같이 내용 추가.
[auth.hook.custom_access_token]
enabled = true
uri = "pg-functions://postgres/private/custom_jwt_token_hook"
=> 정상 동작 하는것 확인
이것을 시도 해보겠습니다. !!
!해피 코딩
[참고사항]
코드를 작성하고 돌려볼때 user_profiles의 권한 관련된 문제가 발생할 수도 있습니다.
저는 migration하다 문제가 생겨서 골치 아팠었는데요.
1. private/custom_jwt_token_hook을 못찾는 문제가 있었습니다.
환경 문제일 수도 있고, 제가 이것 저것 건드려서 생긴 문제일 수도 있습니다.
ALTER FUNCTION private.custom_jwt_token_hook SECURITY DEFINER;
// 원래 invoker로 설정 되어있어도 동작 했던것 같은데,
// SECURITY DEFINER 로 설정을 바꿨습니다.
GRANT EXECUTE ON FUNCTION private.custom_jwt_token_hook TO authenticator;
//권한 설정 auth logic이 authenticator로 동작하는데 함수에 대해서 도 추가로 설정
// authenticator 역할이 실행 권한을 설정
2. user_profiles 접근 권한 문제 발생 했습니다.
RLS 설정을 하여 문제가 없어보이는 상황(제 짤은 생각으로는.. 그렇습니다.^^;;)이었으나 이상하게 접근 권한에 문제가 계속 생겨서 SQL Editor에서 다음과 같이 권한을 줬습니다. 그 이후 기대했던대로 동작 했습니다.
GRANT SELECT ON TABLE public.user_profiles TO authenticated;
3. View 문제
View는 RLS 를 설정 할 수 없습니다. 이걸로 좌절하고 주말을 보냈는데, 찾다보니 방법이 있더군요.
ALTER VIEW my_view SET (security_invoker = on);
이렇게 설정을 하면 my_view 에서 query하는 table에 RLS가 적용 됩니다.
다만 이렇게 했을때 문제는 my_view 가 접근하는 모든 table에 RLS가 잘 적용 되어있어야 동작 한다는 것입니다.
a table은 접근 권한이 있고 b table은 접근 권한이 없으면 퍼미션 에러가 발생합니다.
(이건 시스템을 어떻게 설계하느냐의 문제이기 때문에 이런 부분 고려해서 설계하면 좋겠네요)
