@restrict 실수 3가지 — 빠뜨리면 큰일 #shorts #SAP #CAP

이 글이 답하는 질문

• CAP CDS에서 @restrict를 빠뜨리면 실제로 무슨 일이 생기나?
• grant / to / where 는 언제 어떻게 쓰나?
• 인증된 사용자 vs 특정 역할 — 어떻게 구분해 제한하나?

직접 해보기

1. @restrict 없는 서비스 — 보안 구멍

// @restrict 미적용 → 로그인 없이도 누구나 접근
service CustomerService {
  entity Customers as projection on db.Customers;
}

CAP은 기본적으로 deny-by-default가 아닙니다. @restrict 없으면 서비스 엔드포인트가 전 세계에 열립니다.

2. @restrict 기본 형태

service CustomerService {
  @restrict: [
    { grant: 'READ', to: 'authenticated-user' },
    { grant: ['WRITE','DELETE'], to: 'CustomerAdmin' }
  ]
  entity Customers as projection on db.Customers;
}

authenticated-user는 CAP 내장 pseudo-role — 로그인한 모든 사용자를 뜻합니다.

3. where 절로 행 수준 제어

@restrict: [
  {
    grant: 'READ',
    to: 'authenticated-user',
    where: 'createdBy = $user'
  }
]

본인이 만든 레코드만 읽을 수 있게 필터링합니다. $user는 현재 로그인한 userId로 자동 바인딩됩니다.

삽질 노트

• @readonly vs @restrict: @readonly는 HTTP 메서드만 막음, 인증 체크 없음.
• 서비스 레벨 @restrict: 서비스 전체에 선언하면 모든 엔티티에 상속되지만, 엔티티 레벨이 서비스 레벨을 오버라이드합니다.
• roles 대소문자: XSUAA role template 이름과 정확히 일치해야 합니다 — 오타 한 글자가 권한 오류 대신 silent pass로 이어집니다.

핵심 한 줄

@restrict 없는 CAP 엔티티는 잠긴 척하는 열린 문 — grant/to/where 세 요소로 인증·역할·행 수준 제어를 묶어야 합니다.