Django REST Framework 보안 설정 완벽 가이드 2026 — 실무에서 바로 적용하는 API 보호 전략 총정리

이 글을 끝까지 읽으시면 DRF 프로젝트에 인증·권한·Rate Limiting·CORS 설정까지 실전 코드 그대로 적용해서, 운영 서버에 배포해도 불안하지 않은 수준의 보안 체계를 직접 구축할 수 있습니다.

안녕하세요, ICT리더 리치입니다. Django REST Framework로 API를 완성하고 배포까지 마쳤을 때의 뿌듯함, 다들 한 번쯤 느껴보셨을 겁니다. 그런데 그 뿌듯함이 며칠을 못 가는 경우가 생각보다 많습니다.

실제로 DRF 기반 서비스를 운영하는 팀 중 상당수가 permission_classes를 기본값 그대로 두거나, Throttling 설정 없이 로그인 엔드포인트를 열어둔 채 서비스합니다. 문제는 이런 설정이 화면에서는 아무 이상 없이 잘 동작한다는 점입니다. 서버 로그나 DB를 직접 열어보기 전까지는 공격이 진행 중인지조차 모르는 경우가 대부분입니다.

오늘은 DRF 프로젝트에서 반드시 점검해야 할 보안 설정을 인증 방식 선택부터 권한 클래스, Throttling, CORS, 시크릿 관리까지 실제 운영 환경 기준으로 하나씩 정리해드리겠습니다. 배포 전 체크리스트로 활용하셔도 좋고, 이미 운영 중인 서비스를 점검하는 용도로 쓰셔도 바로 도움이 됩니다.

📌 바로가기 목차

1. DRF 보안, 왜 기본 설정만으로는 위험한가 2. 인증 방식 비교 — Session vs Token vs JWT, 뭘 써야 할까 3. 권한(Permission) 설정 실수 TOP 6 체크리스트 4. 실전 사고 사례 — Throttling 없이 배포했다가 벌어진 일 5. 기본 설정 vs 강화 설정 — 항목별 비교 추천 6. 운영 배포 전 보안 체크리스트 — 이 순서대로 점검하세요 7. 자주 묻는 질문 (FAQ) 8. 마무리 요약

Django REST Framework 보안 설정 완벽 가이드 여성 썸네일

Django REST Framework 보안 설정 가이드를 주제로 인증, 권한, Rate Limiting 핵심 내용을 강조한 여성 개발자 중심 블로그 썸네일

1. DRF 보안, 왜 기본 설정만으로는 위험한가

사실 대부분의 개발자가 모르는 게 있는데요, Django REST Framework는 설치 직후 기본값이 의도적으로 "느슨하게" 잡혀있습니다.

공식 문서에도 명시돼 있지만, DEFAULT_PERMISSION_CLASSES의 기본값은 AllowAny입니다. 즉 별도 설정을 하지 않으면 모든 API 엔드포인트가 인증 없이 누구나 접근 가능한 상태로 열려있다는 뜻입니다.

OWASP API Security Top 10 2023 리포트를 보면 API 보안 사고의 1위 원인이 "Broken Object Level Authorization"이고, 2위가 "Broken Authentication"입니다. 둘 다 DRF의 permission_classes와 authentication_classes를 제대로 설정하지 않아서 생기는 문제와 직결됩니다.

여러분 프로젝트의 settings.py를 지금 한번 열어보시겠어요? REST_FRAMEWORK 딕셔너리 안에 DEFAULT_PERMISSION_CLASSES가 명시적으로 적혀있나요, 아니면 비어있나요?

다음 섹션에서는 인증 방식 자체를 어떻게 선택해야 하는지, Session·Token·JWT 세 가지를 직접 비교해서 정리해드리겠습니다.

2. 인증 방식 비교 — Session vs Token vs JWT, 뭘 써야 할까

의외로 이 질문에 명확히 답하는 팀이 드뭅니다. "그냥 JWT 쓰면 되는 거 아닌가요?"라는 질문을 정말 많이 받는데, 결론부터 말하면 프로젝트 구조에 따라 답이 완전히 달라집니다.

제가 컨설팅했던 한 핀테크 스타트업은 모바일 앱 단일 클라이언트였는데도 SessionAuthentication을 그대로 쓰다가 CSRF 토큰 처리 때문에 모바일 SDK 쪽에서 계속 401 오류가 터졌습니다. 반대로 어드민 대시보드 하나만 운영하는 내부 시스템에 JWT를 무리하게 도입해서 Refresh Token 관리 로직만 며칠을 잡아먹은 사례도 봤습니다.

지금 운영 중인 서비스가 모바일 앱 전용인지, 웹 브라우저 기반인지, 아니면 둘 다인지 한번 떠올려보세요. 이 기준 하나만으로도 인증 방식의 절반은 결정됩니다.

비교 항목	SessionAuthentication	TokenAuthentication	JWT (SimpleJWT)
적합한 클라이언트	브라우저 기반 SPA	내부 도구·단순 API	모바일 앱·MSA 환경
서버 상태 저장	필요 (DB/캐시)	필요 (DB)	불필요 (Stateless)
CSRF 대응 필요성	필수	불필요	불필요
토큰 만료 제어	서버에서 즉시 무효화 가능	서버에서 즉시 무효화 가능	만료 전까지 유효(블랙리스트 필요)
확장성(MSA)	약함	약함	강함

모바일 앱이나 여러 서비스로 쪼개진 MSA 구조라면 JWT + Refresh Token Rotation이 거의 정답에 가깝고, 단일 서버에 브라우저 클라이언트만 붙는다면 SessionAuthentication도 충분히 안전합니다.

3. 권한(Permission) 설정 실수 TOP 6 체크리스트

권한 설정 실수는 보안 사고 중에서도 가장 조용히, 가장 오래 방치되는 유형입니다. 화면에는 아무 문제 없이 잘 동작하니까요.

실제로 작년에 검토했던 한 커머스 플랫폼은 주문 상세 API에서 IsAuthenticated만 걸어두고 본인 주문인지 확인하는 로직(Object-level permission)이 빠져있었습니다. 로그인만 하면 다른 사용자의 주문 ID를 URL에 넣어서 누구나 조회할 수 있는 상태였죠. 이게 바로 IDOR(Insecure Direct Object Reference)입니다.

여러분의 ViewSet 중에 get_queryset()을 오버라이드하지 않고 Model.objects.all()을 그대로 쓰는 곳이 있다면, 지금 바로 의심해보셔야 합니다.

전역 기본 권한 미설정: DEFAULT_PERMISSION_CLASSES를 명시하지 않아 모든 뷰가 AllowAny로 동작하는 경우.
Object-level permission 누락: IsAuthenticated만 걸고 "본인 데이터인지"를 검증하는 has_object_permission을 빠뜨리는 경우.
queryset 필터링 누락: get_queryset()에서 request.user 기준 필터링 없이 전체 데이터를 그대로 반환.
관리자 전용 액션 노출: destroy, update 같은 위험 액션에 별도 IsAdminUser 권한을 추가하지 않은 경우.
Serializer 필드 과다 노출: fields = '__all__' 설정으로 비밀번호 해시·내부 ID 등 민감 필드까지 응답에 포함.
디버그 모드 운영 배포: DEBUG=True 상태로 배포해 에러 발생 시 스택 트레이스와 설정값까지 그대로 노출.

⚠️ 주의: 위 6가지 중 3개 이상에 해당한다면 지금 운영 중인 서비스는 이미 노출 위험 상태일 가능성이 높습니다. 다음 섹션에서 실제로 Throttling이 빠져서 벌어진 사고 사례를 보여드리겠습니다.

Django REST Framework API 보안 설정 남성 개발자 인포그래픽

DRF API 서버의 인증 방식, 권한 설정, Throttling, JWT, HTTPS, 배포 전 보안 점검 항목을 남성 개발자 중심으로 표현한 보안 인포그래픽

▶ 실전 코드 ① — Object-level Permission + queryset 필터링으로 IDOR 완전 차단

권한 설정 실수 TOP 6 중 가장 치명적인 두 가지, Object-level Permission 누락과 queryset 필터링 누락을 동시에 해결하는 커스텀 Permission 클래스입니다.

IsOwnerOrAdmin 클래스는 has_permission()으로 비인증 사용자를 뷰 진입 단계에서 먼저 차단하고, has_object_permission()으로 본인 소유 여부를 객체 단위로 재검증하는 이중 방어 구조를 갖습니다. getattr()로 소유자 필드명을 유연하게 처리해 여러 모델에 재사용할 수 있도록 설계했습니다.


# permissions.py — 커스텀 Object-level Permission 클래스
from rest_framework import permissions


class IsOwnerOrAdmin(permissions.BasePermission):
    """
    본인 소유 객체만 수정/삭제 허용.
    관리자(is_staff=True)는 모든 객체 접근 가능.
    조회(SAFE_METHODS)는 인증된 사용자 전체 허용.
    """

    def has_permission(self, request, view):
        # 1단계: 뷰 진입 자체는 인증된 사용자만 허용 (비인증 즉시 차단)
        return request.user and request.user.is_authenticated

    def has_object_permission(self, request, view, obj):
        # 2단계: GET/HEAD/OPTIONS 안전한 메서드는 통과
        if request.method in permissions.SAFE_METHODS:
            return True

        # 관리자는 PUT/PATCH/DELETE 전체 허용
        if request.user.is_staff:
            return True

        # 핵심: 객체 소유자 == 현재 요청자 동일 여부 검증 (IDOR 차단)
        # getattr로 소유자 필드명 유연 처리 → 모델별 재사용 가능
        # (owner / user / author / created_by 등 모델에 맞게 변경)
        return getattr(obj, 'owner', None) == request.user

has_permission()과 has_object_permission()을 모두 구현하는 것이 핵심입니다.

has_permission()만 있으면 뷰 진입은 막지만 객체 단위 소유권 검증이 빠지고, has_object_permission()만 있으면 비인증 사용자가 뷰에 진입할 수 있는 허점이 생깁니다. 두 메서드를 함께 구현해야 진입 단계와 객체 단계 모두 막는 완전한 이중 방어가 됩니다.

💡 실전 팁: has_object_permission()은 get_object()가 호출될 때만 실행됩니다. list()·create() 같은 컬렉션 레벨 액션에는 적용되지 않으므로, 반드시 아래 코드 ②의 get_queryset() 필터링과 함께 사용해야 이중 방어가 완성됩니다.

▶ 실전 코드 ② — ViewSet 통합 적용: queryset 필터링 + Serializer 필드 화이트리스트

코드 ①의 Permission 클래스를 실제 ViewSet에 연결하고, queryset 레벨 필터링과 Serializer 명시적 필드 제한까지 한 번에 묶은 실전 통합 코드입니다.

get_queryset()에서 request.user 기준으로 필터링하면 list() 호출 시 타인의 데이터가 쿼리셋 자체에 포함되지 않아 IDOR의 진입로를 원천 차단합니다. Serializer에서 fields = '__all__' 대신 허용 필드를 직접 나열해 비밀번호 해시·내부 키 등 민감 정보 노출도 함께 막습니다.


# serializers.py — 민감 필드 노출 차단 (fields 화이트리스트)
from rest_framework import serializers
from .models import Order


class OrderSerializer(serializers.ModelSerializer):
    class Meta:
        model = Order
        # ❌ fields = '__all__'  → 절대 금지: 결제키·내부ID 등 전부 노출
        # ✅ 응답에 포함할 필드만 명시적으로 나열 (화이트리스트 방식)
        fields = [
            'id',
            'product_name',
            'quantity',
            'status',
            'created_at',
        ]
        # owner, payment_key, internal_ref_id 등은 목록 미포함 → 응답 제외
        read_only_fields = ['id', 'created_at']


# views.py — ViewSet 통합: Permission + queryset 필터링
from rest_framework import viewsets
from rest_framework.throttling import ScopedRateThrottle
from .permissions import IsOwnerOrAdmin
from .serializers import OrderSerializer
from .models import Order


class OrderViewSet(viewsets.ModelViewSet):
    serializer_class = OrderSerializer

    # 코드 ①에서 만든 커스텀 Permission 적용
    permission_classes = [IsOwnerOrAdmin]

    def get_queryset(self):
        # 핵심: 전체 데이터가 아닌 본인 데이터만 필터링 반환
        # objects.all() 그대로 반환하면 IDOR 취약점 직결
        return Order.objects.filter(owner=self.request.user)

    def perform_create(self, serializer):
        # 생성 시 owner를 자동으로 현재 요청자로 지정 (클라이언트 임의 지정 차단)
        serializer.save(owner=self.request.user)

perform_create()에서 owner를 서버가 직접 지정하는 부분이 중요합니다.

클라이언트가 요청 바디에 owner 필드를 임의로 넣어도 서버 측에서 덮어쓰기 때문에, 타인 명의로 데이터를 생성하는 공격을 차단할 수 있습니다. get_queryset() 필터링과 perform_create() 소유자 고정이 한 세트로 동작해야 생성·조회·수정·삭제 전 구간이 안전하게 보호됩니다.

💡 실전 팁: 관리자 전용 뷰가 별도로 필요하다면 IsOwnerOrAdmin 대신 IsAdminUser만 걸린 별개의 ViewSet을 만드는 것이 더 명확합니다. 하나의 ViewSet에 조건 분기를 과도하게 쌓으면 권한 로직이 복잡해져 오히려 실수가 생기기 쉽습니다.

⚠️ 주의: DEFAULT_PERMISSION_CLASSES를 전역 IsAuthenticated로 설정한 상태에서 뷰별 permission_classes를 지정하면 전역값이 완전히 대체됩니다. 즉 뷰에 [IsOwnerOrAdmin]만 적용하면 IsAuthenticated가 함께 동작하지 않으므로, 코드 ①처럼 has_permission()에서 인증 여부를 반드시 직접 검증해야 합니다.

4. 실전 사고 사례 — Throttling 없이 배포했다가 벌어진 일

의외로 많은 팀이 Rate Limiting을 "나중에 트래픽 늘면 적용하면 되는 것" 정도로 생각합니다. 저도 그렇게 생각했던 적이 있어서 이해는 합니다만, 실제로는 정반대입니다.

작년에 점검했던 한 교육 플랫폼은 /api/login/ 엔드포인트에 throttle_classes를 전혀 설정하지 않은 채 서비스하고 있었습니다. 공격자가 단 하나의 IP에서 분당 1,200건 이상의 로그인 시도를 자동화 스크립트로 돌렸고, 결과적으로 유출된 이메일 리스트 3만 건을 대상으로 한 크리덴셜 스터핑 공격에 그대로 노출됐습니다. DB 서버 CPU는 한때 95%까지 치솟았고, 정상 사용자들은 로그인 자체가 안 되는 장애로 이어졌습니다.

여러분의 로그인·회원가입·비밀번호 재설정 API에는 지금 몇 번까지 시도가 허용되나요? 한번 직접 테스트해보시길 권합니다.

다음 섹션에서는 이런 사고를 막기 위한 기본 설정과 강화 설정을 항목별로 직접 비교해드리겠습니다.

Django REST Framework 보안 설정 완벽 가이드 여성 개발자 인포그래픽

Django REST Framework의 인증, 권한, Rate Limiting, CORS, 배포 전 보안 체크리스트를 여성 개발자 중심 인포그래픽

5. 기본 설정 vs 강화 설정 — 항목별 비교 추천

DRF 기본값과 운영 환경에서 실제로 써야 하는 강화 설정값은 생각보다 차이가 큽니다. 아래 표는 제가 보안 점검할 때 가장 먼저 확인하는 6가지 항목을 기준값과 함께 정리한 것입니다.

설정 항목	기본 설정 (위험)	강화 설정 (권장)
DEFAULT_PERMISSION_CLASSES	AllowAny (미설정 시)	IsAuthenticated 전역 기본
DEFAULT_THROTTLE_RATES	제한 없음	로그인 5/min, 일반 100/min
CORS_ALLOWED_ORIGINS	CORS_ALLOW_ALL_ORIGINS=True	화이트리스트 도메인만 명시
SECRET_KEY 관리	settings.py에 하드코딩	환경변수 + Secrets Manager
DEBUG	True (배포 후 미수정)	False + ALLOWED_HOSTS 명시
HTTPS 강제	미설정	SECURE_SSL_REDIRECT=True

결론적으로, 이 6가지 항목만 강화 설정으로 바꿔도 실제 사고로 이어지는 경로의 대부분을 차단할 수 있습니다.

6. 운영 배포 전 보안 체크리스트 — 이 순서대로 점검하세요

체크리스트는 많이 봤어도 "순서"까지 신경 쓰는 경우는 드뭅니다. 저는 보안 점검할 때 항상 같은 순서로 봅니다. 인증 → 권한 → 입력 검증 → 통신 보안 순으로 가야 빠뜨리는 게 없습니다.

1단계 - 전역 인증/권한 확인: DEFAULT_AUTHENTICATION_CLASSES, DEFAULT_PERMISSION_CLASSES가 모두 명시적으로 설정됐는지 확인합니다.
2단계 - Throttling 적용: 로그인·회원가입·비밀번호 재설정처럼 민감한 엔드포인트에 별도 Throttle Scope를 지정합니다.
3단계 - Serializer 필드 점검: 모든 Serializer에서 fields='__all__' 대신 명시적 필드 목록을 사용하고 있는지 확인합니다.
4단계 - 환경변수 분리: SECRET_KEY, DB 비밀번호, 외부 API 키가 코드에서 완전히 분리되어 .env 또는 Vault로 관리되는지 확인합니다.
5단계 - HTTPS·헤더 강제: SECURE_SSL_REDIRECT, SECURE_HSTS_SECONDS, X-Frame-Options 설정으로 통신 계층을 강화합니다.
6단계 - DEBUG/ALLOWED_HOSTS 최종 확인: 배포 직전 DEBUG=False, ALLOWED_HOSTS에 실제 도메인만 명시됐는지 마지막으로 점검합니다.

다음 FAQ에서 자주 헷갈리는 부분을 정리했어요.

💻 실전 코드 ③ — 바로 쓰는 DRF 보안 강화 설정 스크립트

위 체크리스트를 실제 코드로 옮기면 다음과 같습니다. settings.py 전역 보안 설정, Object-level Permission 클래스, 그리고 로그인 전용 Throttle 설정까지 운영 환경에 바로 적용 가능한 형태로 작성했습니다.


# settings.py — REST_FRAMEWORK 전역 보안 강화 설정
import os

REST_FRAMEWORK = {
    # 인증 방식: JWT를 기본으로, 세션 인증은 어드민용으로만 유지
    'DEFAULT_AUTHENTICATION_CLASSES': (
        'rest_framework_simplejwt.authentication.JWTAuthentication',
        'rest_framework.authentication.SessionAuthentication',
    ),
    # 전역 기본 권한을 반드시 IsAuthenticated로 — AllowAny 금지
    'DEFAULT_PERMISSION_CLASSES': (
        'rest_framework.permissions.IsAuthenticated',
    ),
    # 전역 Throttling — 익명/인증 사용자별 분당 호출 제한
    'DEFAULT_THROTTLE_CLASSES': (
        'rest_framework.throttling.AnonRateThrottle',
        'rest_framework.throttling.UserRateThrottle',
        'rest_framework.throttling.ScopedRateThrottle',
    ),
    'DEFAULT_THROTTLE_RATES': {
        'anon': '20/min',
        'user': '100/min',
        # 로그인·비밀번호 재설정 등 민감 엔드포인트 전용 스코프
        'login': '5/min',
        'password_reset': '3/hour',
    },
}

# 시크릿 키와 DB 비밀번호는 반드시 환경변수에서 로드
SECRET_KEY = os.environ['DJANGO_SECRET_KEY']  # 하드코딩 절대 금지

DEBUG = os.environ.get('DJANGO_DEBUG', 'False') == 'True'
ALLOWED_HOSTS = os.environ.get('DJANGO_ALLOWED_HOSTS', '').split(',')

# 통신 계층 보안 강제
SECURE_SSL_REDIRECT = True
SECURE_HSTS_SECONDS = 31536000
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
X_FRAME_OPTIONS = 'DENY'

# CORS — 화이트리스트 방식만 허용, 와일드카드 금지
CORS_ALLOWED_ORIGINS = os.environ.get('CORS_ALLOWED_ORIGINS', '').split(',')
CORS_ALLOW_ALL_ORIGINS = False

DEFAULT_THROTTLE_RATES에 login과 password_reset 스코프를 별도로 분리한 게 핵심입니다.

이렇게 하면 일반 API는 분당 100회까지 허용하면서도, 크리덴셜 스터핑 공격의 표적이 되는 로그인 엔드포인트만 따로 분당 5회로 강하게 제한할 수 있습니다.

모든 보안 값은 settings.py에 직접 적지 않고 os.environ으로 분리했기 때문에, .env 파일이나 AWS Secrets Manager로 손쉽게 교체 가능합니다.


# permissions.py — Object-level Permission으로 IDOR 방어
from rest_framework import permissions


class IsOwnerOrReadOnly(permissions.BasePermission):
    """본인 소유 객체만 수정/삭제 가능, 조회는 인증 사용자 전체 허용"""

    def has_object_permission(self, request, view, obj):
        # GET, HEAD, OPTIONS 같은 안전한 메서드는 통과
        if request.method in permissions.SAFE_METHODS:
            return True
        # 그 외 메서드(PUT, PATCH, DELETE)는 본인 소유인지 검증
        return obj.owner_id == request.user.id


# views.py — ViewSet에 적용하는 예시
from rest_framework import viewsets
from rest_framework.throttling import ScopedRateThrottle
from .permissions import IsOwnerOrReadOnly
from .models import Order
from .serializers import OrderSerializer


class OrderViewSet(viewsets.ModelViewSet):
    serializer_class = OrderSerializer
    permission_classes = [IsOwnerOrReadOnly]

    def get_queryset(self):
        # 핵심: 전체 데이터가 아닌 본인 데이터만 필터링해서 반환
        return Order.objects.filter(owner_id=self.request.user.id)


class LoginThrottleView(viewsets.ViewSet):
    throttle_classes = [ScopedRateThrottle]
    throttle_scope = 'login'  # settings.py의 login 스코프(5/min) 적용

get_queryset()에서 owner_id로 필터링하는 부분이 IDOR 방어의 핵심입니다.

has_object_permission은 객체가 조회된 "이후" 검증이라 이중 방어가 되고, get_queryset 필터링은 그 객체가 아예 조회 대상에 들어오지 않게 막아줍니다. 두 가지를 함께 적용해야 안전합니다.

💡 실전 팁: ScopedRateThrottle을 쓸 때는 throttle_scope를 ViewSet 단위가 아니라 액션 단위로도 분리할 수 있습니다. get_throttles() 메서드를 오버라이드해서 create 액션에만 다른 스코프를 적용하면 더 정교한 제어가 가능합니다.

Django REST Framework 보안 설정 대표 이미지 여성 개발자

Django REST Framework 보안 설정을 상징하는 자물쇠 아이콘과 여성 개발자 이미지를 활용해 제작한 텍스트 없는 대표 썸네일

7. 자주 묻는 질문 (FAQ)

Q DRF에서 JWT랑 Session 인증을 같이 써도 되나요?

네, 가능하고 실무에서 흔히 쓰는 방식입니다. DEFAULT_AUTHENTICATION_CLASSES에 두 가지를 순서대로 등록하면 DRF가 위에서부터 차례로 인증을 시도합니다. 일반 API는 JWT, 어드민 페이지는 Session으로 분리하는 구조가 가장 안정적입니다. 2번 인증 방식 비교에서 각각의 장단점을 더 자세히 확인하실 수 있어요.

Q DEFAULT_PERMISSION_CLASSES를 IsAuthenticated로 바꾸면 기존 공개 API는 다 막히는 건가요?

전역 기본값을 바꿔도 특정 뷰에서 permission_classes = [AllowAny]를 개별 지정하면 그 뷰만 공개로 유지됩니다. 회원가입이나 공개 게시글 목록처럼 인증이 필요 없는 엔드포인트만 화이트리스트 방식으로 풀어주는 게 안전합니다. 3번 권한 설정 체크리스트도 함께 참고해보세요.

Q Throttling을 적용하면 정상 사용자도 차단당할 위험이 있지 않나요?

맞습니다, 그래서 일반 API와 민감 엔드포인트의 스코프를 분리하는 게 핵심입니다. 일반 조회는 분당 100회 정도로 여유 있게, 로그인 같은 민감한 액션만 분당 5회로 좁게 제한하면 정상 사용자 불편은 거의 없습니다. 5번 설정 비교표의 권장값을 기준으로 시작해보시길 추천합니다.

Q SECRET_KEY를 환경변수로 옮기는 게 정말 그렇게 중요한가요?

매우 중요합니다. SECRET_KEY가 노출되면 세션 위조, CSRF 토큰 위조까지 가능해져서 사실상 인증 체계 전체가 무력화됩니다. 특히 GitHub에 settings.py를 그대로 올리는 실수가 의외로 자주 발생하니, 6번 배포 체크리스트의 4단계를 꼭 확인하세요.

Q CORS_ALLOW_ALL_ORIGINS을 True로 켜놓으면 실제로 얼마나 위험한가요?

악성 사이트가 사용자의 인증 쿠키나 토큰을 이용해 여러분의 API를 대신 호출할 수 있게 됩니다. 특히 인증된 상태의 브라우저에서 CSRF 공격과 결합되면 피해가 커집니다. 운영 환경에서는 반드시 CORS_ALLOWED_ORIGINS에 실제 프론트엔드 도메인만 화이트리스트로 등록하세요. 더 궁금한 점은 댓글로 남겨주세요!

8. 마무리 요약

✅ 핵심 정리

DRF의 기본 설정은 의도적으로 느슨하게 잡혀있다는 사실 하나만 기억하셔도 오늘 글의 절반은 챙긴 셈입니다.

DEFAULT_PERMISSION_CLASSES를 IsAuthenticated로 명시하고, 로그인 엔드포인트에 별도 Throttle 스코프를 걸고, get_queryset()에서 본인 데이터만 필터링하는 이 세 가지만 적용해도 흔히 발생하는 사고의 대부분을 막을 수 있습니다.

보안은 한 번에 완벽하게 끝내는 작업이 아니라, 매 배포마다 체크리스트를 다시 훑어보는 습관입니다.

지금 당장 할 수 있는 첫 행동은 하나입니다 — settings.py를 열어서 DEFAULT_PERMISSION_CLASSES가 명시돼 있는지부터 확인해보세요. 비어있다면 오늘 글의 6단계 체크리스트 순서대로 하나씩 적용해보시길 권합니다.

여러분의 DRF 프로젝트에서 가장 먼저 점검하고 싶은 보안 항목은 무엇인가요? 댓글로 알려주시면 다음 포스팅에서 그 부분을 더 깊게 다뤄드리겠습니다!

📌 다음 포스팅 예고: Django + Celery 비동기 작업 보안 설정 완전 가이드 — 백그라운드 큐도 안전하게 지키는 법도 곧 업로드됩니다. 놓치지 않으려면 구독과 알림 설정 부탁드립니다!

React, Vue, Angular 비교 분석 – 내 프로젝트에 가장 적합한 JS 프레임워크는?

- 10월 14, 2025

이 블로그 검색

ICT리더 리치