[내일배움캠프 36일차] _ 보안을 위해 고민한 것들

✂️삭제에 대하여

유저와 같은 중요한 정보를 삭제하려고 할 때,
비밀번호 검증을 통해 본인이 시도를 하고 있는 것인지를 확인하는 과정이 필요하다.

비밀번호는 보안을 위해 파라미터가 아닌 RequestBody를 사용해 넘겨주어야 한다.
그러나 DELETE 메서드는 RequestBody를 사용하지 않는 것이 좋다고 한다.

❓ 그러면 삭제를 무엇으로 하나요?

주로 PATCH를 사용한다.

또는

세션이나 토큰 등을 이용해 비밀번호 검증이 된 상태에서만 삭제를 허용한다.

(PATCH 사용에 대해서는 여전히 고려해야 할 부분이 있다.)

---

💡 Soft Delete 논리 삭제, Hard Delete 물리 삭제

논리 삭제와 물리 삭제는 삭제를 했을 때, 해당 데이터가 DB에 계속 남아있는가 아닌가의 차이이다.

예를 들어, 네이버 카페가 있다고 가정해 보자.

유저 1이 "test1"이라는 닉네임으로 여러 글을 남긴 후 탈퇴했다.
이후 다른 유저가 "test1"이라는 닉네임으로 카페에서 활동을 한다면
기존 사용자들은 이전 "test1" 유저와 새로운 "test1" 유저의 행동이 달라 혼란을 느낄 수 있다.

따라서 우리는 "test1" 유저 탈퇴 시, 해당 유저를 삭제하지만 닉네임 중복 방지를 위해
"test1"이라는 정보가 여전히 필요하다.

이런 상황에 사용하는 것이 Soft Delete 방식이다.

Soft Delete 논리 삭제

논리 삭제는 실제 데이터를 DB에서 삭제하지 않는다.
다만, is_deleted와 같이 삭제 여부를 나타내는 boolean 변수를 통해 상태를 변경하여
삭제된 것처럼 처리한다.

Hard Delete 물리 삭제

물리 삭제는 DB에서 해당 데이터를 실제로 제거하는 것이다.

PATCH와 DELETE 사용은 비밀번호 검증의 여부가 아닌
삭제 방식에 따라 사용하는 메서드가 달라지고, 주로 PATCH를 사용한다.

위에서 언급했다시피 비밀번호가 이미 인증되었다는 가정하에 DELETE를 사용할 수도 있다.

💡 PATCH 사용 시, 해커를 주의하세요!

대규모 프로젝트에서는 PATCH를 통한 삭제를 권장하지 않는다.

논리 삭제를 하지 않는다는 말이 아니다.
논리 삭제여도 PATCH 메서드 대신 DELETE 메서드를 사용한다는 것이다.

PATCH는 메서드명 자체로 해커에게
"이 기업은 삭제된 정보를 보관합니다!"라는 힌트를 줄 수 있다.

따라서, DELETE 메서드를 사용하는 곳도 있다고 한다.
(회사 규칙에 따라 상이하다.)

이런 부분이 있다 정도로만 이해해도 좋을 것 같다.

---

🔐비밀번호 변경

유저가 변경 가능한 필드가 다음과 같이 있다고 가정하자.

1. 닉네임
2. 소개
3. 성별 
4. 생년월일
5. 비밀번호

이 정보들을 수정하는 API를 만들고자 할 때, API를 어떻게 나누면 좋을까?

📑 각 필드에 따라 변경하는 API 만들기 (👎 비추천 )

필드의 개수가 많아질수록 API 개수가 늘어나기 때문에 좋은 방법이 아니다.

 

♥️ 추천) 유저 정보 변경과 비밀번호 변경을 분리해서 관리

닉네임과 성별처럼 간단하거나, 소개처럼 공백이 허용되는 필드의 변경은
별도의 검증 없이 바로 적용해도 무방한 부분들이다.

이런 필드들은 PUT을 이용해 업데이트하는 방법이 선호된다고 한다!

❓ 변경 가능한 필드를 일부만 변경하고 싶을 때도 PATCH가 아닌 PUT 사용이 가능한가?

가능하다.

닉네임, 소개, 성별, 생년월일 중 소개만 변경하고 싶다고 할 때,
프런트에서 변경된 소개를 제외한 나머지 부분을 기존 값 그대로 입력해 주면 되는 것이다!

{
    "이름" : "현재값",
    "소개" : "변경된 값",
    "성별" : "현재값"
    ...
}

 

위와 같은 방식으로 정보를 업데이트할 때,
비밀번호는 검증과 암호화 같은 비즈니스 로직이 추가된다.

따라서, 비밀번호를 변경하는 API와 비밀번호를 제외한 나머지 유저 정보를 변경하는 API
이렇게 2개로 나누는 방법이 제일 좋은 것 같다! (개인적인 생각)

 

📦 하나의 API로 모든 정보를 수정하기

상황에 따라 다를 것 같다.

1. 비밀번호가 검증되어야만 정보가 변경되도록 하는 경우

정보 변경 시, 비밀번호 검증이 필수라면 나쁘지 않은 방법이라고 생각된다.

2. 변경 시, 비밀번호가 필요 없는 경우

• PATCH 방식으로 새로운 값이 입력된 필드만 변경되도록 할 때

변경하지 않는 필드의 경우 null이 허용되기 때문에
컨트롤러 계층에서 유효성 검증이 어렵다는 단점이 있다.

컨트롤러 계층에서 @Validate 또는 @Valid로 유효성 검증을 하지 못하는 경우,
직접 클래스를 만들어서 유효성 검증을 해야 한다.

실무에서는 유효성 검증에 다음과 같은 방법을 보편적으로 사용한다고 하니 참고하면 좋을 것 같다.

https://jay-cheol.tistory.com/entry/JAVA%EA%B0%84%EB%8B%A8%ED%95%9C-%ED%8C%A8%EC%8A%A4%EC%9B%8C%EB%93%9C-Validator-%EB%A7%8C%EB%93%A4%EA%B8%B0

[JAVA] 정규식을 이용하여 패스워드 Validator 만들기!

 

• PUT 방식으로 새로운 값이 입력되지 않은 필드는 프런트에서 기존 값을 입력할 때

프런트가 비밀번호를 알고 있어야 한다는 점에서 좋지 못한 방법이라고 생각된다.

 

---

😵 마무리

비밀번호를 다루는 부분에서 들었던 개인적인 고민들과 그에 대한 구글링, 튜터님들께 질문한 결과를
바탕으로 정리를 해보았다.

이 글을 통해 나 같은 고민을 하는 사람들에게 조금이나마 도움이 될 수 있으면 좋겠다.
(To.Me From.Me😜)

개인적인 생각도 많이 들어가 있는데, 잘못된 정보 수정 요청이나 논의는 언제나 환영입니다~😊