Http 메소드가 문제가 아니라 url에 민감정보를 집어넣는 게 핵심인건데 대체 왜 아직도 애꿎은 메소드 걸고 넘어지는 지 모르겠다


패킷스니핑 당하면 get이고 post고 나발이고 의미 없다. http는 털리는거고 https는 안털리는거다


마찬가지로 post 바디에 민감정보 넣으면 안전하고 get 헤더에 민감정보 넣으면 위험한가?


깊게 파고들면 미세한 차이가 있긴 하지만 일반적으론 그렇지 않다


이놈의 메소드 보안성 타령은 먼 옛날에 url에다가 민감정보를 그대로 쑤셔박던 인간들 때문에 생긴거다


브라우징 히스토리나 웹서버 로그에는 url 내역이 남는다


이 때문에 민감정보를 url 안에다가 넣어버리면 로그 안에 민감정보도 같이 저장된다


이런 이유로 url에다가 민감정보 찍어넣지 말자는 약속이 생겼는데 대체 이게 어떻게 왜곡이 된 건지 get 요청 쓰지 말자는 결론이 만들어졌고 그게 구전되면서 아직도 post 는 안전하고 get 은 위험하다는 요상한 주장이 끊이질 않는 것이다


진짜로 굳이 굳이 굳이 트집을 잡자면 "웹서버 중 바디는 로그 남기는 경우가 드문 반면 헤더는 로그 남기는 경우도 있으니까 post 바디에 민감정보 넣는게 더 안전하지 않을까?" 하는 주장을 펼 수도 있을 것이다


하지만 일반적으론 웹서버 로깅 설정에 헤더값 안 남기게 해놓는 선에서 끝낸다


다들 이미 알겠지만 요즘 웹 서비스는 단순 데이터 조회라면 get 요청 헤더에다가 api 키 값 넣는 선에서 끝내는 게 일반적이다


'웹서버가 헤더값을 로그에 남기더라도 안전하게끔 단순 데이터 조회조차도 싹 다 post 메소드로 만들어야지'


이건 너무 나간거고 솔직히 post 보안성 타령하는 놈들 중에서 이 정도까지 깊게 생각해서 post 쓰는 놈은 별로 본 적이 없다




결론)

그냥 get 좀 쓰자