면접대비 질문 정리: 웹, HTML, CSS

면접질문 참고

• https://nomadcoders.co/community/thread/3979
• [diary] 프론트엔드 신입 면접 준비하기
• [면접준비] 프론트엔드 개발자 취업 면접 질문 및 답변 정리(64문)
• 프론트엔드 면접질문 중요도별 정리
• [Frontend] 프론트엔드 주니어 개발자 면접 질문 (기술/인성)

 

1. 브라우저 작동 원리 (주소창에 google.com을 입력하면 일어나는 일)

(사용자가 브라우저에 주소를 입력한 후에 서버로부터 전송된 데이터가 화면에 보이기까지 그 일련의 과정을 설명할 수 있어야 합니다.)

 

✅ 답변

브라우저에 도메인을 입력하면, 브라우저는 해당 IP 주소를 얻기 위해 DNS(Domain Name System) 서버에 요청을 보내 IP주소를 받아옵니다. IP 주소를 받은 브라우저는 해당 요청을 IP 주소와 일치하는 서버로 전달합니다. (이때 서버와의 통신은 HTTP 프로토콜을 사용하여 이루어지고, 모든 데이터는 TCP/IP 프로토콜을 이용해 전송됩니다.) 다음으로 서버는 웹 사이트의 파일들을 데이터 패킷이라 불리는 데이터의 덩어리들로 브라우저에 전송해 주고, 웹 브라우저는 이렇게 받은 데이터를 기반으로 페이지를 화면에 렌더링하게 됩니다.

 

참고: 

• https://www.reason-to-code.com/blog/why-do-they-ask-about-browser-rendering/
• https://tkdev.tistory.com/86

 

2. 브라우저 렌더링 원리

✅ 답변

렌더링 엔진(webkit, gecko)이 HTML, CSS, JS로 렌더링할 때는 Critical Renderding Path(CRP)라는 프로세스를 거칩니다.

각 단계를 설명해 보자면 첫번째로 HTML을 파싱한 후 DOM트리를 구축하고 두번째로는 CSS를 파싱해 CSSOM 트리를 구축합니다. 이후에 JS를 실행하고 DOM과 CSSOM을 조합해서 렌더트리를 구축합니다. 그 후에 뷰포트를 기반으로 렌더트리의 각 노드가 가지는 정확한 위치와 크기를 계산(reflow)하고 최종적으로 이렇게 계산한 위치와 크기를 기반으로 화면에 그림을 그리게(repaint) 됩니다.

 

참고: https://github.com/baeharam/Must-Know-About-Frontend/blob/main/Notes/frontend/browser-rendering.md

 

 

3. CORS 에러의 정의와 특징, 해결 방법⭐

✅ 답변

CORS란 Cross-origin-Resource-Sharing의 준말이며 해석하면 교차 출처 자원 공유입니다.

데이터를 주고받는 과정에서 브라우저는 보안을 위해 웹 어플리케이션에서 외부 출처(origin)로의 HTTP 요청을 제한합니다. 따라서 도메인 이름이 서로 다른 사이트 간 API 요청이 이루어질 때 개발자가 공유 가능한 도메인을 따로 설정해주지 않는다면 데이터 전송 과정에서 에러가 발생합니다.

CORS 에러가 발생했을 때의 해결방법은 백엔드 코드에서 Access-Control-Allow-Origin 헤더에 알맞은 외부 사이트 주소를 등록해 프론트엔드 측에 응답해 주는 것입니다.

 

참고:

• https://ksmfou98.github.io/Interview/%EA%B8%B0%EC%88%A0%20%EB%A9%B4%EC%A0%91%204%ED%83%84/
• CORS에러 (Infa 블로그)
• HTTP (갓대희 블로그)

 

4. 클라이언트 사이드 렌더링과 서버 사이드 렌더링 (CSR vs SSR)⭐

각각의 특징, 장단점 등

 

✅ 답변

클라이언트 사이드 렌더링(CSR)과 서버 사이드 렌더링(SSR)은 웹 애플리케이션을 구축하는 데 사용되는 두 가지 주요 렌더링 방식입니다. 각각의 특징, 장단점을 설명드리겠습니다.

 

클라이언트 사이드 렌더링 (CSR)

Client-Side Rendering의 약자로, 브라우저(클라이언트)에서 렌더링을 처리합니다. 초기 로딩 시에 클라이언트 측에서 HTML, JS, 필수 리소스들을 다운로드하고, 이후에 클라이언트 측에서 자바스크립트를 사용하여 동적으로 컨텐츠를 업데이트합니다. 사용자의 요청이 올 때마다 서버에서 데이터를 가져와서 클라이언트 측에서 렌더링합니다.

장점:

1. 서버 부담 감소: 화면에서 변화가 일어나는 만큼의 데이터만 요청하기 때문에 웹 서버 호출을 최소화할 수 있습니다.
2. 빠른 UX: 초기 로딩 속도는 느리지만, 이후에는 빠른 UX를 제공합니다.
3. 인터랙티브한 UI: 클라이언트 측에서 렌더링을 처리하므로, 인터랙티브하고 동적인 UI를 쉽게 구현할 수 있습니다.

단점:

1. 초기 로딩 속도: 초기 로딩 시에 모든 자바스크립트 파일을 다운로드하고 실행해야 하기 때문에 초기 로딩 속도가 느릴 수 있습니다.
2. SEO 문제: 최초 로딩 시 HTML이 비어 있어 SEO(Search Engine Optimization) 측면에서 불리할 수 있습니다.
3. 저사양 기기에서 성능 문제: 클라이언트 측에서 모든 렌더링을 처리하기 때문에, 저사양 기기에서는 성능 문제가 발생할 수 있습니다.

서버 사이드 렌더링 (SSR)

Server-Side Rendering의 약자로, 서버 측에서 초기 페이지 렌더링을 완료한 후 클라이언트에 전달하는 방식입니다. 서버에서 HTML을 생성하여 클라이언트에 전송하므로, 초기 로딩 속도가 빠르고 SEO에 유리합니다.

장점:

1. 초기 로딩 속도: 서버에서 완성된 HTML을 전달하기 때문에 초기 로딩 속도가 빠릅니다.
2. SEO에 유리: 서버에서 완성된 HTML을 전송하므로, 검색 엔진 크롤러가 쉽게 내용을 파악할 수 있어 SEO에 유리합니다.
3. 일관된 초기 화면: 서버에서 렌더링된 HTML을 전달하기 때문에 초기 화면이 깜빡임 없이 안정적입니다.

단점:

1. 서버 부담 증가: 모든 요청에 대해 서버가 HTML을 생성해야 하기 때문에 서버 부담이 증가할 수 있습니다.
2. 페이지 이동 시 깜빡임: 클라이언트가 새로운 페이지를 요청할 때마다 서버에서 전체 페이지를 다시 받아오기 때문에 페이지 이동 시 깜빡임 현상이 발생할 수 있습니다.
3. 상호작용 늦어짐: 초기 로딩은 빠르지만, 인터랙티브한 요소들이 로드되기까지 시간이 걸릴 수 있습니다.

혼합 접근 방식

이 두 가지 방식을 혼합하여 사용하는 경우도 있습니다.

예를 들어, Next.js와 같은 프레임워크는 초기 로딩은 서버 사이드 렌더링으로 처리하고, 이후의 인터랙션은 클라이언트 사이드 렌더링으로 처리하는 하이브리드 접근 방식을 제공합니다. 이를 통해 SEO와 성능을 모두 만족시키는 웹 애플리케이션을 구축할 수 있습니다.

프로젝트의 요구 사항, 성능, SEO 등을 고려하여 CSR과 SSR 중 적합한 방식을 선택하거나, 두 가지 방식을 혼합하여 사용하는 것이 중요합니다.

 

참고:

• https://manon-kim.tistory.com/entry/%EB%A9%B4%EC%A0%91%EC%A7%88%EB%AC%B8-%EC%A0%95%EB%A6%AC
• https://amyhyemi.tistory.com/224
• https://tinyurl.com/27x9otzh

 

5. REST API란?

✅ 답변

REST는 REpresentational State Transfer의 약자로, 전반적인 웹 어플리케이션에서 상호작용하는 데 사용되는 웹 아키텍쳐(애플리케이션을 설계, 제작하는 데 사용하는 패턴과 기술의 총칭) 모델입니다. 웹 애플리케이션 상에 존재하는 모든 리소스에 대해 고유 URI를 부여하고 HTTP Method(GET, POST, PUT, DELETE)를 이용해 CRUD 명령을 적용하는 개념입니다.

API란 Application Programming Interface의 약자로, 여러 응용 프로그램의 상호 통신 방법을 규정하고 데이터 교환을 도와주는 매개체입니다.

REST API라는 것은 REST 원칙을 적용하여 서비스 API를 설계한 것을 말하고, 대부분의 서비스가 REST API를 제공하고 있습니다.

 

참고: 

• REST(Representational State Transfer)란?
• REST API란?
• API란? API의 정의와 종류 그리고 장단점

 

6. 브라우저 저장소의 차이점 (LocalStorage,SessionStorage,Cookie) 

✅ 답변

HTTP 프로토콜의 중요한 특징 중 하나는 Stateless(무상태성)입니다.

무상태성이란 서버가 클라이언트의 상태 정보를 저장하지 않는다는 것을 의미합니다. 즉 서버는 클라이언트의 인증상태와 같은 상태정보를 저장하고 있지 않기 때문에 통신을 할 때마다 클라이언트가 인증요청을 해야 한다는 단점이 있습니다. 이를 보완하기 위해 등장한 것이 쿠키와 HTML5의 웹 스토리지입니다.

 

먼저, 쿠키는 서버가 사용자의 브라우저에 전송하는 키-값 구조의 문자열입니다. 브라우저는 서버가 전송한 쿠키 데이터를 로컬에 저장해 두었다가, 동일한 서버에 요청을 보낼 때마다 이 쿠키 데이터를 HTTP 요청의 Cookie 헤더에 포함시켜 함께 전송합니다.

쿠키는 최대 4KB의 데이터로 용량이 작고 문자열만 저장할 수 있다는 특징이 있습니다.

모든 HTTP 요청에 쿠키 정보가 포함되어 전송되기 때문에 요청 크기가 커져 네트워크 성능에 영향을 미칠 수 있습니다.

또한 CSRF(교차 사이트 요청 위조) 공격에 취약합니다.

(CSRF: 웹 사이트가 쿠키를 사용해 사용자의 세션을 관리하고 있을 때, 사용자가 로그인 상태에서 공격자가 만든 악의적인 웹페이지에 방문하면 해당 웹페이지는 사용자의 브라우저를 통해 악의적인 요청을 보낼 수 있습니다.)

 

웹 스토리지는 쿠키의 단점을 해결할 수 있는 저장소입니다.

웹 스토리지의 경우 자동으로 정보가 서버로 전송되지 않기 때문에 네트워크 성능에 영향을 미치지 않습니다. 또한 쿠키보다 저장 용량이 크다는 장점이 있습니다.(브라우저에 따라 다르지만 보통 5MB에서 10MB 정도의 데이터를 저장할 수 있습니다.)

웹 스토리지에는 localStorage와 sessionStorage가 있으며

sessionStorage는 탭이나 브라우저가 닫히면 저장된 정보가 삭제되지만,

localStorage는 사용자가 데이터를 삭제하거나 캐시를 삭제하지 않는 한 데이터가 삭제되지 않습니다.

 

참고:

• https://www.youtube.com/watch?v=5s--sLWzuZc&ab_channel=CodeON%EC%BD%94%EB%93%9C%EC%98%A8
• -

 

7. 비동기/동기에 대해 설명

✅ 답변

동기는 요청을 보낸 후 기다렸다가 해당 응답을 받고 나서 다음 동작을 실행하는 것을 의미하고,

비동기는 요청을 보낸 후 응답에 관계없이 순차적으로 다음 코드를 먼저 실행하는 것입니다.

8. DOM에 대해 설명

✅ 답변

Documet Object Model을 뜻하며, 마크업 언어로 작성된 문서를 JavaScript 같은 프로그래밍 언어가 조작할 수 있도록 하는 인터페이스입니다. DOM은 계층 구조를 가진 노드 트리로 구성됩니다.

 

참고:

• 프론트맨 - DOM 개념 설명 유튜브

 

9. HTTP Method에 대해 설명

✅ 답변

GET은 리소스를 조회하는 역할을 하고,

POST는 등록 및 요청 데이터를 처리합니다.

PUT은 리소스를 덮어쓰지만 해당 리소스가 없다면 새로 생성해줍니다.

PATCH는 리소스의 일부분을 변경합니다.

PUT, PATCH는 데이터를 수정한다는 면에서 공통점이 있지만, PUT은 전체 데이터를 변경하는 반면 PATCH는 리소스의 일부만 변경한다는 차이점이 있습니다.

마지막으로 DELETE는 리소스를 삭제하는 역할을 합니다.

 

이 외에도 Head, Options, Connect, Trace 메소드가 존재합니다.

HEAD: GET과 동일하나 메시지 부분(Body)를 제외하고, 상태 줄과 헤더만 반환

OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명 (주로 CORS에서 사용)

CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정

TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

 

 

10. CSS의 Box-model

✅ 답변

모든 HTML 요소는 BOX 모양으로 구성되며, 이것을 박스모델이라고 합니다.

각 element는 가운데 실제 element의 내용이 담긴 부분(content), element를 감싸는 경계(border), border와 content 사이의 영역(padding), border 바깥의 영역(margin)으로 구성됩니다.

 

 

11. CSS의 position

✅ 답변

CSS의 position 속성은 HTML 요소의 배치 방식을 결정하는 데 사용됩니다. position 속성에는 5가지 속성값이 존재하며, 각 값은 요소가 문서 내에서 어떻게 배치되고 다른 요소와 어떻게 상호작용하는지를 결정합니다. 

 

1. static

• 기본값으로, 요소가 일반적인 문서 흐름에 따라 배치됩니다.
• 좌표 프로퍼티(top, right, bottom, left)가 적용되지 않습니다.
• 기본값이므로, position 속성을 명시하지 않으면 모든 요소는 static으로 배치됩니다.

2. relative

• 요소를 일반적인 문서 흐름에 따라 배치하되, 좌표 프로퍼티(top, right, bottom, left)를 사용하여 기준 위치에서 이동시킵니다.
• 다른 요소들의 위치에는 영향을 주지 않고, 요소 자신만 이동합니다.
• 좌표 프로퍼티가 설정되지 않으면 static과 동일하게 작동합니다.

3. absolute

• 요소를 문서 흐름에서 제거하고, 가장 가까운 relative, absolute, fixed, sticky 부모 요소를 기준으로 배치합니다. 만약 부모 요소가 없으면, 초기 컨테이닝 블록(HTML 문서 자체)을 기준으로 배치됩니다.
• 좌표 프로퍼티를 사용하여 정확한 위치를 지정할 수 있습니다.
• 요소는 일반적인 문서 흐름에서 제거되므로, 공간을 차지하지 않습니다.

4. fixed

• 요소를 문서 흐름에서 제거하고, 뷰포트(브라우저 창)를 기준으로 배치합니다.
• 좌표 프로퍼티를 사용하여 정확한 위치를 지정할 수 있습니다.
• 스크롤과 상관없이 항상 같은 위치에 고정되어 있습니다.
• 요소는 일반적인 문서 흐름에서 제거되므로, 공간을 차지하지 않습니다.

5. sticky

• 요소는 기본적으로 문서 흐름에 따라 배치되지만, 스크롤 위치에 따라 요소가 고정됩니다.
• 특정 임계점을 지나면 요소가 fixed처럼 뷰포트에 고정됩니다.
• 좌표 프로퍼티(top, right, bottom, left) 중 최소 하나가 설정되어야 합니다.
• 요소는 스크롤 위치에 따라 relative와 fixed 사이를 전환합니다.

 

12. JSON(JavaScript Object Notation)에 대해 설명

✅ 답변

• JavaScript 객체 문법으로 구조화된 데이터 교환 형식
• python, java, js 등 여러 언어에서 데이터 교환형식으로 사용됩니다.
• 객체문법 이외에 단순배열, 문자열도 표현 가능합니다.
• key-value 값으로 구성되어 있습니다.
• 이미 존재하는 키를 중복 선언하면 나중에 선언한 해당 키에 대응한 값이 덮어 씌워지게 됩니다.
• JSON 데이터를 읽고 쓰는 데 사용되는 JavaScript 함수에는 JSON.parse()와 JSON.stringify()가 있습니다. JSON.parse()는 JSON 형식의 문자열을 JavaScript 객체로 변환하고, JSON.stringify()는 JavaScript 객체를 JSON 형식의 문자열로 변환합니다.

 

13. HTTP 프로토콜

✅ 답변

1. HTTP란 무엇인가요? 어떤 프로토콜인가요?
   • HTTP는 Hypertext Transfer Protocol의 약자로, 웹 상에서 데이터를 주고받는 프로토콜입니다.
2. HTTP 요청과 응답의 구조를 설명해주세요.
   • HTTP 요청은 요청 라인, 헤더, 본문으로 구성되며, HTTP 응답은 상태 라인, 헤더, 본문으로 구성됩니다.
3. HTTP 메서드(GET, POST, PUT, DELETE 등)에 대해 설명해주세요. 각각 어떤 역할을 수행하나요?
   • HTTP 메서드는 클라이언트가 서버에게 요청하는 동작을 나타냅니다.
   • GET은 데이터를 가져오는 데 사용되고, POST는 데이터를 생성하는 데 사용되며, PUT은 데이터를 업데이트하는 데 사용되고, DELETE는 데이터를 삭제하는 데 사용됩니다. PATCH는 PUT과 마찬가지로 데이터를 업데이트하는 데 사용되지만 PUT이 데이터 전부를 덮어쓰는 반면 PATCH는 일부 데이터만 수정할 수도 있습니다.
4. HTTP 상태 코드란 무엇인가요? 몇 가지 예를 들어 설명해주세요.
   • HTTP 상태 코드는 서버가 클라이언트에게 응답할 때 응답의 성공, 실패 등의 상태를 나타내는 코드입니다. 예를 들어, 200은 성공을 의미하고, 404는 찾을 수 없음을 의미합니다.
5. HTTPS가 HTTP와 어떻게 다른가요? 왜 보안 연결에 HTTPS를 사용해야 하나요?
   • HTTPS는 HTTP의 보안 버전으로, 데이터를 암호화하여 보안 연결을 제공합니다. 보안 연결이 필요한 경우, 개인 정보와 같은 민감한 데이터를 전송할 때 HTTPS를 사용해야 합니다.

 

14. CSS의 display

출처: 스택오버플로우

✅ 답변

block

• 요소가 화면에서 새로운 줄을 차지하며, 부모 요소의 너비를 기본적으로 모두 차지합니다. 너비와 높이를 자유롭게 설정할 수 있습니다.
• 예시: `div`, `h1`, `p`, `section` 등의 요소가 기본적으로 block입니다.
• 장점: 레이아웃을 구성할 때 유용하며, 모든 방향의 margin과 padding을 정확히 적용할 수 있습니다.

 

inline

• 요소가 줄바꿈 없이 한 줄에 연속해서 배치됩니다. 텍스트처럼 취급되며, 요소의 너비와 높이는 콘텐츠에 따라 결정됩니다.
• 예시: `span`, `a`, `strong` 등의 요소가 기본적으로 inline입니다.
• 한계: 너비와 높이, 상하 여백(margin), 패딩을 정확하게 조절하기 어렵습니다.

 

inline-block

• inline과 block의 특징을 결합한 형태입니다. 요소가 줄바꿈 없이 한 줄에 배치되지만, block 요소처럼 너비와 높이, 패딩을 설정할 수 있습니다.
• 예시: 버튼이나 이미지 등을 정렬할 때 자주 사용됩니다.
• 장점: 여러 개의 inline-block 요소를 한 줄에 배치하면서도 개별적으로 크기 조정이 가능합니다.

 

15. JWT

1. JWT란 무엇이며 어떻게 작동하는지 설명해주세요.

✅ 답변

• JWT란 Json Web Token의 줄임말로써 사용자 인증 수단입니다.
• 사용자가 로그인하면 서버는 JWT를 생성하고, 이를 사용자에게 반환합니다.
• 클라이언트가 서버로 요청을 보낼 때마다 JWT를 함께 전송합니다.
• JWT는 토큰 자체에 사용자 정보를 포함하고 있으므로, 서버는 데이터베이스에 대한 추가적인 조회를 필요로 하지 않습니다. 이는 서버의 부하를 줄일 수 있습니다.
  • 이때 서버는 verify라는 함수를 통해 JWT의 유효성을 검증하고, 필요한 데이터를 추출하여 요청을 처리합니다.

 

2. JWT을 사용하는 이유는 무엇인가요? 다른 인증 방법과 비교했을 때의 장단점은 무엇인가요?

✅ 답변

1. 상태를 관리하지 않음(Stateless): JWT는 서버 측에서 세션을 관리할 필요가 없기 때문에 서버의 확장성이 높아집니다. 특히 분산된 시스템에서 사용하기에 유리합니다.
2. 편의성: JWT는 JSON 형식으로 데이터를 저장하므로 파싱이 간편하고, 데이터를 손쉽게 전달할 수 있습니다.
3. 보안: JWT는 서명(Signature)과 암호화(Encryption)를 사용하여 토큰의 유효성을 검증할 수 있습니다. 이를 통해 데이터의 무결성을 보장할 수 있습니다.
4. 널리 지원됨: JWT는 다양한 플랫폼과 언어에서 지원되며, 표준화되어 있어 쉽게 사용할 수 있습니다.

JWT vs 세션 기반 인증 장단점 비교

• JWT는 상태를 관리하지 않으므로 서버 측의 부하가 적습니다. 그러나 세션 기반 인증은 서버 측에서 상태를 관리하기 때문에 세션 스토리지가 필요하고 확장성이 떨어질 수 있습니다.
• 세션 기반 인증은 서버 측에서 세션을 만료시키거나 관리해야 하므로 관리가 복잡할 수 있습니다.

요약하자면, JWT는 상태를 관리하지 않고, 편리하며 보안성이 뛰어나므로 인증 및 권한 관리에 많이 사용됩니다. 그러나 적절한 사용을 위해서는 보안 사항에 주의해야 합니다.

 

 

3. JWT의 구성 요소에는 어떤 것들이 있나요? 각 구성 요소의 역할을 설명해주세요.

✅ 답변

JWT는 Header, Payload, Signature 총 세 가지 구성요소로 이루어져 있습니다.

Hedaer는 JWT의 타입과 사용할 해시 알고리즘을 지정합니다. Payload에는 실제로 전송하려는 정보가 담겨있고 이 정보는 클레임으로도 불립니다. signature는 토큰을 인코딩하거나 유효성 검증을 할 때 사용하는 고유한 암호화 코드입니다. 인코딩된 header와 payload, 헤더의 알고리즘을 사용하여 생성됩니다.

 

 

4. JWT의 보안 측면에서 주의해야 할 점은 무엇인가요? 보안 위험이 있는 상황을 방지하기 위한 조치는 무엇인가요?

✅ 답변

1. 비밀 키 관리

• 주의 사항: JWT 서명에 사용되는 비밀 키가 유출되면, 공격자가 JWT를 위조할 수 있습니다.
• 조치: 비밀 키를 안전하게 저장하고, 필요시 주기적으로 변경합니다. 환경 변수나 안전한 키 관리 시스템을 활용합니다.

2. 알고리즘 취약점

• 주의 사항: JWT에서 사용하는 서명 알고리즘(예: HS256, RS256)이 취약할 수 있습니다. 특히, 비공식적인 알고리즘(예: "none" 알고리즘)을 사용하면 보안 문제가 발생할 수 있습니다.
• 조치: 강력한 알고리즘을 사용하고, 알고리즘을 명시적으로 설정합니다.

3. 토큰 만료

• 주의 사항: JWT에 만료 시간이 설정되지 않으면, 토큰이 무한정 사용될 수 있습니다.
• 조치: exp 클레임을 사용하여 토큰의 만료 시간을 설정하고, 토큰이 만료되면 재인증을 요구합니다.

4. 재사용 공격

• 주의 사항: JWT가 중간에 가로채이거나 재사용될 수 있습니다.
• 조치: HTTPS를 사용하여 데이터 전송을 암호화하고, JWT를 수명 주기가 끝난 후에는 폐기합니다. 사용자가 로그아웃할 때 토큰을 무효화합니다.

5. 클레임의 검증

• 주의 사항: JWT의 클레임을 검증하지 않으면, 공격자가 데이터를 조작할 수 있습니다.
• 조치: 토큰을 검증할 때 모든 클레임을 확인하고, 필요한 경우 추가적인 검증 로직을 추가합니다.

6. 정보 노출

• 주의 사항: JWT의 페이로드에 민감한 정보를 포함하면, 토큰이 유출될 경우 문제가 발생할 수 있습니다.
• 조치: 페이로드에는 최소한의 정보만 포함하고, 민감한 정보는 암호화하거나 다른 방법으로 보호합니다.

 

---

 

 

 

 

양방향 바인딩, 단방향 바인딩

header, body 구분

로그인 페이지 구현 - 아이디, 비밀번호를 서버로 전송 후 체크하고 세션이나 쿠키로 ~ HTTP 헤더, JSON Body 관련 이야기

네트워크 예외처리 - status code, try catch, axios 네트워크 라이브러리 공통 에러처리 방법