flawopen.com/Mass Assignment/설명
Mass Assignment: 위험과 안전한 필드 허용 목록
모델을 사용자 편집란과 직원 전용 제어 항목이 있는 양식이라고 생각하세요. 요청 전체를 바인딩하면 고객이 소유자, 승인, 역할까지 입력할 수 있습니다. 편집 필드는 서버에서 정하고 레코드와 작업을 각각 인가하세요.
# Rails: request keys reach model attributes User.new(params[:user]) // Node / Mongoose: request object used as update await User.findByIdAndUpdate(id, req.body); // Express + Sequelize: request object used as create values await User.create(req.body); # Django: request keys passed as model fields User.objects.create(**request.POST.dict())
# Rails — permit only user-editable fields attrs = params.require(:user).permit(:name, :email) user = User.new(attrs) // Node — construct an allowlisted update const { name, email } = req.body; await User.findByIdAndUpdate(id, { name, email }); # Django — explicit ModelForm fields class UserForm(ModelForm): class Meta: model = User fields = ["name", "email"] // .NET — bind a DTO, then map explicitly user.Name = input.Name; user.Email = input.Email;
서버 측 허용 목록이 중요한 이유
“role 외 모두 허용” 같은 차단 목록은 새 민감 필드가 추가되면 실패할 수 있습니다. 허용 목록에서는 코드가 열기 전까지 새 필드를 수정할 수 없습니다. Rails Strong Parameters는 대량 할당에서 허용되지 않은 속성을 거부하지만 컨트롤러는 작업에 필요한 필드만 허용해야 합니다. DTO나 명시적 필드 목록도 같은 경계를 만듭니다.
허용 목록은 요청 속성을 제한하지만 레코드 변경 권한은 주지 않습니다. 인증 주체 범위로 제한하고 작업을 인가하며 권한 변경은 별도 서버 흐름에 둡니다.
검토할 민감 필드 범주
모델 속성, 중첩 직렬화기, 업데이트 엔드포인트에서 확인하세요:
- ✓소유자 및 테넌트 키 — user_id, account_id, tenant_id. 서버에서 소유권을 강제하고 클라이언트 값을 신뢰하지 마세요.
- ✓역할, 권한, 워크플로 상태 — role, is_admin, email_verified, status. 인가된 서버 절차에서만 변경하세요.
- ✓금융 값과 중첩/시스템 필드 — 잔액, 할인, 크레딧, 관계, 타임스탬프, ID는 업무 규칙이나 업데이트 범위에 영향을 줍니다. 각 필드를 의도적으로 허용하고 검증하세요.
자주 묻는 질문
서로 다른 취약점입니다. Mass Assignment는 객체에 의도하지 않은 속성을 설정합니다. Prototype pollution은 프로토타입 속성을 바꾸어 다른 객체의 조회에 영향을 줄 수 있습니다. 안전하지 않은 병합이 원인이 될 수 있지만 결과는 속성 사용 방식에 달려 있습니다. prototype pollution을 참고하세요.
아니요. GraphQL mutation도 넓은 입력을 받을 수 있습니다. 입력 타입을 허용 필드로 제한하고 resolver나 서비스에서 인가하세요.
아니요. 폼은 HTTP 전송을 제한하지 않습니다. 모든 필드를 신뢰하지 말고 서버에서 구조를 검증한 뒤 해당 작업의 필드만 받으세요.