6주차 멘토링

2021-11-30

참여자
- J077_문혜현, J107_송명회, J218_홍승용, J219_홍종우, 성지현 멘토님
시간
- 19:30 ~ 20:45

멘토님 문의 드릴 사항

HTTPS 를 사용하는데 Refresh Token이 필요한가요?
- HTTPS를 쓰는 순간 Sniffing 공격이 불가하기 때문에 Refresh Token이 큰 의미가 없지만, Token 탈취 자체는 발생할 수 있는 사항이다.
- 그런 상황일 때, Refresh Token 자체가 유효하지만, Cookie에 담아서 전달하는 순간 어차피 Token은 다 탈취됨.
- DB에서 내부적으로 Token 값을 비교하는 것이 보안적으로 성능적으로 효과적일 것으로 보임
CSRF 공격의 정확한 의미, CORS를 하게 되면 막을 수 있는 것 아닌가요?
- Browser 상에서 공격하려는 Site로 공격자가 피싱 사이트로 접속하게 하였을 때, Form 데이터를 입력하게 하여 해당 작업을 바꾸는 API를 받으면 Cookie 정보가 전달되어 인증 처리가 되면서 게시물이 삭제되거나 변경될 수 있음.
  - https://대상_사이트/출금?amount=10000000
- POST등은 CORS를 걸게 되면 막을 수는 있는데, 개발 하다보면 CORS를 열어줄 수 밖에 없는 경우가 있어서 공격 당할 여지가 있음.
  - (credentials: same-origin)하면 됨
  - (sameSite는 더 강력함)
- 혹여나 Submit 등을 진행했을 때, Target Browser가 바뀌어 있는 경우에는 CORS로 막을 수 없다.
  - fetch는 CORS로 막을 수 있겠지만 browser URL이 바뀌면 불가
  - 이 때는 Referer 체크 또는 Cookie의 SameSite를 걸어서 CSRF 공격을 막을 수 있다.(쿠키 자체가 전달되지 않게 할 수 있다.)
Routing 이슈
- 이슈 내용
  - 로그인 시 Recoil 값을 확인 후, 없으면 Private Route를 통해 Cookie를 Backend에 보내서 Response를 받아와 실제 페이지를 보여주는 형식
  - 즉, 새로고침을 하거나 URL Routing을 직접 하는 경우에도 Cookie를 사용해 자동 로그인이 구현되어 있음.
  - 그런데, 페이지 같은 경우에는 Login 하지 않은 사람은 들어가서는 안되는 Page의 경우, Recoil을 확인해서 Backend로 보내거나 보내지 않거나 하고 있는데
  - MainPage는 Login 여부와 상관이 없이 보여주어야 하는데, Header에서 Recoil 확인 처리를 진행하기에 그런 경우의 Routing을 어떻게 처리해야 하는지가 의문
  - 또, Private Route가 Profile 페이지에도 있었는데, Modal도 URL 방식으로 이동되게 되어 있어서 Route가 걸려 있는데, 2개의 Page를 렌더링 하는 방식임.
  - 그 때, 같은 요청을 2번 보내게 되는 방식이라서 Background 및 Modal을 어떻게 처리해야 할지가 고민이 됨.
- 접근법
  - MapComponent만 사용자 정보 fetch를 제외하는 방향(useEffect를 Header에서 사용해서 어떤 것을 Rendering 할지 결정)
  - Double Rendering은 이미 1회만 보내서 Recoil로 체크하기 때문에 문제가 없음
Docker
- 빌드 시간을 줄일 수밖에 없다. (React, backend)
  - tree-shaking, webpack 등
- 무중단 배포는 빌드 끝나고 전환하는 방식
인스턴스 사양
- CPU 사용량 20~30%정도..
- 결국 스트레스 테스트를 해봐야 안다.
  - nGrinder, jmeter 등 툴이 있다. locust?
발표 내용 Feedback
- MongoDB : 확장, sharding이 장점. 확장성 있는 서비스를 만드려고 했다는 어필을 가미하면 좋을 것 같다.
- Text index: MongoDB는 한글에 대해 형태소 분석을 지원하지 않아서 오히려 안좋을듯.
  - 해당 부분은 Indexing을 적용한 과정을 넣는 것이 더 나을 것 같음.(확인 방법, 잘 동작하는지, 성능 향상)
- mongodb scehma 설계에 대한 애기가 더 있으면 좋고, 로직이나 그림이 더 들어가면 좋을 것 같다
- 앞으로 개선해야할 것들 등 예상 질문을 몇 개 더 생각해보자
테스트
- API 테스트를 왜 해야 되지?
  - (중요 로직에 대한)유닛 테스트는 어쨌든 작성하는 게 좋다.
- 테스트를 작성해보는게 좋을까?
  - 하는게 좋겠지만 시간적으로 괜찮을지..
  - 테스트의 가장 큰 장점: 배포 전에 확인할 수 있다는 점
    - 시간이 된다면 이런 시나리오를 발생시켜보고 테스트를 통해 해결했다 이런 식으로..
예상 가능한 케이스들을 최대한 만든다. test case를 만드는 가장 큰 이유는 CI에서 에러를 잡아서 배포하기 전에 고치기 위함.
CSR 렌더링 최적화 (서버)
- NGINX에서 제공하는 gzip압축
- NGINX에서 번들 파일 캐싱(Cache-Control), 웹캐시 유효 여부에 대한 Tag 확인