https://www.youngju.dev/blog 천천히 올바르게. AI Researcher & DevOps Engineer Youngju's blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, and data engineering — plus mindset essays on confidence, routines, health, and sport psychology. ko fjvbn2003@gmail.com (Youngju Kim) fjvbn2003@gmail.com (Youngju Kim) Sun, 26 Jul 2026 00:00:00 GMT https://www.youngju.dev/blog/security/2026-07-26-authentication-vs-authorization-idor.en https://www.youngju.dev/blog/security/2026-07-26-authentication-vs-authorization-idor.en Most real data breaches come from authorization, not authentication. The classic case is IDOR, where the login passes normally but changing only the ID in the URL returns another user resource verbatim. This post separates authentication from authorization at the code level, and explains precisely why swapping sequential IDs for UUIDs is a mitigation rather than a fix. It covers why authorization checks scattered across controllers always leave a gap and therefore have to be centralized in the data access layer or a policy engine, the pattern for forcing a tenant condition into every query in a multi-tenant system along with PostgreSQL row level security settings, automated tests that cross-call every route with two accounts, and why detection only works when deny decisions are written to the audit log. Sun, 26 Jul 2026 00:00:00 GMT fjvbn2003@gmail.com (Youngju Kim) securityauthorizationidorapimulti-tenant https://www.youngju.dev/blog/security/2026-07-26-authentication-vs-authorization-idor.ja https://www.youngju.dev/blog/security/2026-07-26-authentication-vs-authorization-idor.ja 実際のデータ漏洩事故のほとんどは認証ではなく認可で発生します。ログインは正常に通過したのに URL の ID を変えるだけで別のユーザーのリソースがそのまま返ってくる IDOR が代表例です。この記事では認証と認可の境界をコードレベルで区別し、連番 ID を UUID に変えることがなぜ解決策ではなく緩和策にすぎないのかを正確に説明します。認可チェックをコントローラごとに散らすと必ず抜ける箇所が出るので、データアクセス層かポリシーエンジンへ中央化すべき理由、マルチテナントでテナント条件をクエリに強制するパターンと PostgreSQL の行レベルセキュリティの設定、二つのアカウントで全ルートを交差呼び出しする自動テスト、そして監査ログに拒否の記録を残さなければ検知できない理由まで扱います。 Sun, 26 Jul 2026 00:00:00 GMT fjvbn2003@gmail.com (Youngju Kim) securityauthorizationidorapimulti-tenant https://www.youngju.dev/blog/security/2026-07-26-authentication-vs-authorization-idor https://www.youngju.dev/blog/security/2026-07-26-authentication-vs-authorization-idor 실제 데이터 유출 사고의 대부분은 인증이 아니라 인가에서 발생합니다. 로그인은 정상적으로 통과했는데 URL의 ID만 바꾸면 다른 사용자의 리소스가 그대로 반환되는 IDOR가 대표적입니다. 이 글은 인증과 인가의 경계를 코드 수준에서 구분하고, 순차 ID를 UUID로 바꾸는 것이 왜 해결책이 아니라 완화책에 불과한지 정확히 설명합니다. 인가 검사를 컨트롤러마다 흩어 놓으면 반드시 빠지는 곳이 생기므로 데이터 접근 계층이나 정책 엔진으로 중앙화해야 하는 이유, 다중 테넌트에서 테넌트 조건을 쿼리에 강제하는 패턴과 PostgreSQL 행 수준 보안 설정, 두 계정으로 모든 라우트를 교차 호출하는 자동 테스트, 그리고 감사 로그에 거부 기록을 남겨야 탐지가 되는 이유까지 다룹니다. Sun, 26 Jul 2026 00:00:00 GMT fjvbn2003@gmail.com (Youngju Kim) securityauthorizationidorapimulti-tenant https://www.youngju.dev/blog/security/2026-07-26-authentication-vs-authorization-idor.zh https://www.youngju.dev/blog/security/2026-07-26-authentication-vs-authorization-idor.zh 真实的数据泄露事故大多不是出在认证上，而是出在授权上。最典型的就是 IDOR：登录正常通过，只要改一下 URL 里的 ID，别人的资源就原样返回了。本文在代码层面把认证与授权的边界划清楚，并准确说明把顺序 ID 换成 UUID 为什么只是缓解措施而不是解决方案。文章还会讲清授权检查一旦散落在各个控制器里就必然会有遗漏，因此必须集中到数据访问层或策略引擎；多租户下把租户条件强制进查询的模式与 PostgreSQL 行级安全的配置；用两个账号交叉调用所有路由的自动化测试；以及为什么只有把拒绝记录写进审计日志才谈得上检测。 Sun, 26 Jul 2026 00:00:00 GMT fjvbn2003@gmail.com (Youngju Kim) securityauthorizationidorapimulti-tenant