...
예전에는
'무조건 post 만 쓰라고 강요했다'
'post 가 보안성이 있어서 그나마 낫다'
이렇게 전해들었습니다만...
어차피 요즘은 token 방식으로 해당 요청이 정상적인 요청인지 확인하거나
파라미터를 확인 못하게하려면 보낼때부터 암호화하고 받는쪽에서 복호화만 하면 될거같은데
굳이 post만 쓰는 이유를 모르겠네요.
post도 dev tool 만 열어도 body 값 다 까지고..
역할에 맞는 request 를 보낸다고하면 그냥 http method 를 전부 사용하는게 맞을거 같은데.
delete 는 관련 이슈가 있어서 제외시켰고 전에는 get, post, put 까지만 사용했습니다.
db에서 데이터를 진짜로 삭제하는 케이스는 없었고 대부분 flag 변경이니까요.
uri에서는 전혀 안보이는게 장점이라 보안성면에선 확실히 좋죠
어..이건 몰랐네요.
생각해보니까 그렇네... 브라우저 히스토리에 URI 까지 통으로 기록되기는 하니까...
"POST 가 보안상 더 안전하다" 라는 문장을 보면 피가 살짝 거꾸로 솟는데, 이게 마냥 틀린 말은 아니라서,,
전송 과정의 보안보다는 로그 관련된 문제라고 생각하시면 될 것 같습니다.
도시괴담급 이야기 아닐까요?
늘 그렇듯, 원리를 모르고 결과만 외우는 암기식 교육의 폐해가 어디서나 나옵니다.
찾아보니 이런 포스팅이 있네요.
https://medium.com/@robert.broeckelmann/http-post-vs-get-is-one-more-secure-for-use-in-rest-apis-2469753121b0
그래도 대기업이라면 짬바가 있고, 정부가이드 같은건 따라야한다는 그런게 있지않나요?
그냥 저냥 맞춰가는 수준이지 엄청 잘한다고 볼수는 없죠.
프랜차이즈 식당 요리사가 최고 요리사는 아니듯이요.
보안정보를 GET 으로 가져오는 개발자도 많습니다.
그냥 잘 몰랐다던가 실수라고 하고 같이 고치면 될것을 항상 물어보면 설계자가 정해주지 않았다 라고 하는데
그런 개발자가 나중에 설계자 되면 정말로 설계서를 꼼꼼하게 안 빠트리고 적어줄건지 찾아가서 보고 싶을 때가 있습니다.
보안은 좀 개발/설계/관리 모두 같이 신경썼으면 하는 바램이 있네여....
응? 보안정보라캄은 주민등록번호같은건가요?
그걸 내부에서 처리안하고 밖으로 조회해야할 이유가 있나요..?
물론 개인정보 보안 취급자는 볼 수 있는 권한이 있긴할텐데...
다른사이트와 연동하면서 Token 사용하지 않고 그냥 ID/PW 로 연동하는 Legacy 가 있었는데
URL 에 ID/PW 를 그대로 실어서 보내는 사이트가 있었던 기억이 있어서여...ㅡㅡ;
개발자 왈 "파라미터키를 id나 pw 가 아니라 다른사람이 알아볼수 없는 걸로 했으니 노출되도 id/pw 인지 모를꺼다...라고 얘기를 하더라구여....."
...키가 다르다고 그걸 못알아보는게 말이야 빙구야...
허허허 대단하네요.
ID/PW는 최소한의 래핑처리는 해서 보내야지....
막줄 정말 공감합니다.
사실 개발/설계/관리 모두가 잘 되고 지켜져야 보안이죠..
보안처리만 해놨다고 다 끝난건 아닌데 말입니다.
http header는 쓰는거 아니라고..
파라미터는 몽땅 post body에 넣어야 한다고...
왜그래야 하냐니까 보안 어쩌고 만 도돌이표... 정확히 설명도 못하고..
oauth... 구글이나 페북이나 그런데도 다 authorization 헤더 쓴다고 하니 ....
어쨌든 안된다고만 하던 ..
은행권 SI하다 넘어온 본부장이랑 도저히 같이 일 모르겠어서 퇴사한 적이 있네요.
뭔가 ... 대기업 SI쪽 미신(?) 같은게 있는거 같아요.