프론트엔드Explorer

이번 포스팅에서는 X-로 시작하는 헤더에 대해 알아보자. 

X-로 시작하는 헤더들은 어떤 의미를 가지고 있을까? 

예전에는 사용자가 임의로 헤더를 정의할 때, 사용자가 정의한 헤더라는 것을 알려주고자

앞에 X-를 붙이곤 했다. 하지만 2012년에 임의라는 의미는 이미 사라졌다. 

이제는 사용자 정의 헤더도 X-를 앞에 붙이지 않아도 된다. (하지만 많은 사람들, 심지어 구글마저 습관적으로 X를 앞에 붙인다고 한다) 

지금은 아니라도 예전에 규칙이었기 때문에 X-를 붙인 헤더들을 많이 볼 수가 있다. 

그 중 몇 헤더들은 너무 널리 쓰여서, 사실상 표준 헤더가 되어 버렸다. 

X- 규칙은 사라졌지만, X-가 앞에 붙은 헤더들 중 유명한 것들은 알아두는 게 좋다. 

X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto

요청이 어디서부터 건너왔는지 알려주는 헤더이다. 

실제 세상에서는 클라이언트(요청)-서버(응답)와 같은 2단 구조보다는,

클라이언트(요청)-중개 서버-중개 서버- ... -최종 서버(응답) 과 같은 다단 구조가 더 많다. 

이 때, 중개 서버를 거치면서 헤더들이 변조되고, 요청을 누가 보냈는지 애매해지기도 한다. 

X-Forwarded 헤더 시리즈는 원래 요청이 누구였는지를 밝혀준다. 

(물론 이것도 조작할 수 있으니 완전히 믿어서는 안 된다.)

X-Forwarded-For: 1.2.3.4, 5.6.7.8, 9.10.11.12
X-Forwarded-Host: www.abc.com
X-Forwarded-Proto: https

For는 현재까지 거쳐온 서버의 IP에 대한 정보를 가지고 있다. 

1.2.3.4가 원래 서버 IP라면 나머지는 중개 서버 IP가 된다. 

Host는 원래 서버의 호스트 명이고, Proto는 원래 서버의 프로토콜이 된다. 

사실, Forwarded 헤더가 표준 헤더이다. 위 세 가지를 모두 처리할 수 있다. 

Forwarded: for=1.2.3.4; host=www.abc.com; proto=https; by=5.6.7.8, 9.10.11.12

X-Frame-Options

frame, iframe, object 태그 안에서 페이지를 렌더링하는 것을 막을 수 있다. 

내 사이트가 frame, iframe, object를 안 쓴 다면 아래처럼 막아두는 게 보안에 좋다. 

클릭재킹(내가 무언가를 눌렀는데, 실제로는 그게 아니라 다른 게 눌리는 해킹 방법)을 막을 수 있다고 한다. 

X-Frame-Options: DENY

만약, 내 사이트 자체를 iframe 등으로 불러오는 경우에는 아래처럼 자신의 페이지를 불러오는 것은 허용할 수 있다. 

X-Frame-Options: SAMEORIGIN

특정한 사이트를 불러오는 것만 허용하고 싶다면 아래와 같이 명시해주면 된다. 

X-Frame-Options: ALLOW-FROM https://www.zerocho.com

X-Content-Type-Options

서버에서 보내온 Content-Type 헤더가 잘못 설정되었다고 생각하는 경우, 

브라우저는 자체적으로 컨텐츠 타입을 추론한다. 

예를 들어, 분명히 css 파일인데 Content-Type 헤더가 text/html인 경우, 

브라우저가 text/css로 추론할 수도 있다는 뜻이다. 

하지만 이런 임의적 행동은 예상치 못한 행동이기 때문에 위험할 수 있다. 

그럴 때는 아래와 같은 헤더를 서버에 보내주어, 브라우저가 서버가 보낸 컨텐츠 타입을 따르게 강제할 수도 있다. 

X-Content-Type-Options: nosniff

이 포스팅은 아래 링크를 참고하여 작성하였습니다.

https://www.zerocho.com/category/HTTP/post/5b611b9e33b4636aa8bb1fc4

이번 포스팅에서는 쿠키와 캐시 헤더만 따로 알아보도록 하자. 

웹 자원을 효율적으로 사용하기 위해서는 캐싱이 중요하다. 

똑같은 데이터를 계속해서 내려 받을 필요는 없다. 

쿠키는 클라이언트(프론트)와 서버 간에 데이터를 주고받는 가장 간단한 방법 중 하나이다. 

이것들에 대한 설정을 헤더를 통해 할 수 있다. 

쿠키나 캐시에 대한 정보는 개발자 도구의 Application 탭에서 쉽게 확인할 수 있다. 

캐시

여기서 말하는 캐시는 개인 캐시를 뜻한다. CDN 같은 공유 캐시가 아니라. 

내 브라우저에 응답으로 온 HTML이나 JSON 같은 데이터가 저장되어, 나중에 서버에 요청을 보내지 않고도 브라우저에 저장된 응답을 사용할 수 있다. 

보통 캐싱은 GET 요청에만 한다. 가져온 데이터를 저장해두고 두고두고 쓰는 것이다. 

일반적으로 200(가져오기 성공), 301(다른 주소로 이동 후 가져옴), 404(가져올 게 없음) 상태 코드로 온 응답을 캐싱할 수 있다. 

Cache-Control

많은 옵션들이 있지만, 자주 쓰이는 옵션만 알아보자. 

먼저, 아무것도 캐싱하지 않으려면 아래처럼 하면 된다. 

Cache-Control: no-store

아래는 가장 많이 헷갈려하는 헤더 설정이다. 

Cache-Control: no-cache

no-cache지만 cache하지 말라는 뜻이 아니다! 

모든 캐시를 쓰기 전에 서버에 이 캐시 써도 되는지 물어보라는 뜻이다. 

must-revalidate는 만료된 캐시만 서버에 확인받도록 하는 것이다.

Cache-Control: must-revalidate

public이면 공유 캐시(또는 중개 서버)에 저장해도 된다는 뜻이고, 

private이면 브라우저 같은 특정 사용자 환경에만 저장하라는 뜻이다. 

Cache-Control: public 또는 private

max-age로 캐시 유효시간을 줄 수 있다. 초 단위이므로 아래 예제는 1시간이다. 

1시간이 지나면 이 응답 캐시는 만료된 것으로 여겨진다. 

Cache-Control: public, max-age=3600

참고로, 위의 옵션들은 혼합해서 써도 된다. 

no-store, no-cache, must-revalidate처럼 콤마로만 구분하면 된다. 

Cache-Control을 응답 헤더라고 생각할 수도 있는데, 요청 헤더로도 사용할 수 있다. 

프론트 - 중개 서버 - 진짜 서버와 같은 구조인 경우에, 중개 서버에 있는 캐시를 가져오지 않도록 하려면

요청 시부터 Cache-Control을 헤더로 넣어주곤 한다. 

Age

Age 헤더는 캐시 응답 때 나타나는데, max-age 시간 내에서 얼마나 흘렀는지를 초 단위로 알려준다. 

위 예제에서 max-age=3600을 설정한 경우, 1분이 지나면 아래와 같이 캐시 응답 헤더에 포함된다. 

Age: 60

Expires

Cache-Conrol과 별개로 응답에 Expires라는 헤더를 줄 수도 있다. 

응답 컨텐츠가 언제 만료되는지를 나타내며, Cach-Control의 max-age가 있는 경우,

이 헤더는 무시된다. 

Expires: Thu, 28 May 2021 07:28:00 GMT

ETag

HTTP 컨텐츠가 바뀌었는지를 검사할 수 있는 태그이다. 

같은 주소의 자원이더라도, 컨텐츠가 달라졌다면 ETag가 다르다. 

예를 들어, GET www.abc.com의 응답 본문이 안녕 html이고, ETag 헤더 값이 12345라 하자. 

만약, 서버 컨텐츠(응답 본문)가 동일하다면 매번 www.abc.com을 할 때마다 ETag는 12345다. 

그런데 안녕 html에서 안녕 javascript로 컨텐츠가 바뀌었다면 ETag 헤더 값도 34567로 바뀐다. 

그러면, 서버가 클라이언트의 응답 내용이 달라졌구나를 깨닫게 되어, 

캐시를 지우고 새로 컨텐츠를 내려받을 수 있게 된다. 

Etag: W/"3bf2-wdj3VvN8/CvXVgafkI30/TyczHk"

If-None-Match

서버에게 ETag가 달라졌는지 검사해 ETag가 다를 경우에만 컨텐츠를 새로 내려주라는 뜻이다. 

만약, ETag가 같다면 서버는 304 Not Modified를 응답해서 캐시를 그대로 사용하게 된다. 

If-None-Match: W/"3bf2-wdj3VvN8/CvXVgafkI30/TyczHk"

쿠키

쿠키는 브라우저에 저장되는 작은 데이터 조각으로, 임시 데이터 보관 또는 웹페이지 개인화 등에 사용된다. 쿠키를 주기적으로 지우지 않으면 브라우저에 엄청나게 많은 쿠키들이 쌓여있는 것을 볼 수 있는데, 이것들이 우리를 추적하고 있는 것이다. 

Set-Cookie

서버에서 클라이언트(브라우저)한테 xx 쿠키를 저장하라고 명령하는 응답 헤더이다. 

Set-Cookie: 키=값; 옵션들

Set-Cookie: hello=dolphin이면 hello라는 키에 값을 dolphin으로 해서 보낼 수 있는 것이다. 

옵션도 몇 개 알아보자. 

• Expires: 쿠키 만료 날짜를 알려줄  수 있다.
• Max-Age: 쿠키 수명을 알려줄 수 있다. Expires는 무시된다. 
• Secure: https에서만 쿠키가 전송된다. 
• HttpOnly: 자바스크립트에서는 쿠키에 접근할 수 없다. XSS 요청을 막으려면 활성화해두는 것이 좋다.
• Domain: 도메인을 적어주면, 도메인이 일치하는 요청에서만 쿠키가 전송된다. 가끔, 도메인이 다른 쿠키들이 있는데, 이런 쿠키들은 써드 파티 쿠키로 우리를 추적하고 있는 쿠키다. 구글이나 페이스북 같은 곳은 써드 파티 쿠키를 적극적으로 사용한다. 
• Path: path를 적어주면 이 path와 일치하는 요청에서만 쿠키가 전송된다. 

예를 들면, 다음과 같이 가능하다. 

Set-Cookie: dolphin=sarah; Expires=Wed, 2 June 2021 07:28:00 GMT; Secure; HttpOnly

쿠키는 XSS 공격과 CSRF 공격 등에 취약하기 때문에, HttpOnly 옵션을 켜두고, 

쿠키를 사용하는 요청은 서버 단에서 검증하는 로직을 꼭 마련해두는 게 좋다. 

Cookie

반대로 클라이언트가 서버에게 쿠키를 보내줄 때는 이 요청 헤더에 담아 보낸다. 

Cookie: 키=값; 키=값;

서버는 이 쿠키 헤더를 파싱해서 사용한다. 

아까도 언급했듯, CSRF 공격 같은 것을 막기 위해서 서버는 반드시 쿠키가 제대로 된 상황에서 온 것인지 확인하는 로직을 갖춰야 한다. 

이렇게 캐시와 쿠키에 관련된 헤더를 알아보았다. 

보통은 알아서 세팅하는 캐시와 쿠키를 사용하지만, 직접 수정해야 할 때도 있으니 그 때 참고하면 좋을 것 같다. 

이 포스팅은 아래 링크를 참고하여 작성하였습니다.

https://www.zerocho.com/category/HTTP/post/5b594dd3c06fa2001b89feb9

이번 포스팅에서는 HTTP 응답 헤더에 대해 알아보자. 

(지난 HTTP 공통 헤더, 요청 헤더 포스팅과 이어집니다.)

2021.05.27 - [CS/네트워크] - [네트워크] 알아두면 좋은 HTTP 공통 헤더와 요청 헤더

응답 헤더 

Access-Control-Allow-Origin

프론트엔드 개발자들이라면 많이 보았을 헤더이다. 프론트 주소와 백엔드 주소가 다르면 CORS 에러가 발생하는데,

이때 서버에서 응답 메시지 Access-Control-Allow-Origin 헤더에 프론트 주소를 적어줘야 에러가 나지 않는다. 

프로토콜, 서브도메인, 도메인, 포트 중 하나만 달라도 CORS 에러가 난다. 

만약, 주소를 일일이 지정하기 싫다면 위처럼 *으로 모든 주소에 CORS 요청을 허용하면 된다.

단, 그만큼 보안이 취약해진다. 

유사한 헤더로 Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Methods, Access-Control-Allow-Headers 등이 있다. 

CORS 요청 시에는 미리 OPTIONS 주소로 서버가 CORS를 허용하는지 물어본다.

이때, Access-Control-Request-Method로 실제로 보내고자 하는 메서드를 알리고, 

Access-Control-Request-Headers로 실제로 보내고자 하는 헤더들을 알린다. 

Allow들은 Request에 대응되는 것으로, 서버가 허용하는 메서드와 헤더를 응답하는데 사용된다.

Request와 Allow가 일치하면 CORS 요청이 이루어지는 것이다. 

Allow

Allow 헤더는 Access-Control-Allow-Methods와 비슷하지만, CORS 요청 외에도 적용된다는 것에 차이가 있다.

즉, GET은 되고, POST는 허용하지 않는 경우, 405 Method Not Allowed 에러를 응답하면서 헤더로 아래와 같이 보내면 된다. GET 요청만 받겠다는 뜻이다. 

Allow: GET

Content-Disposition

응답 본문을 브라우저가 어떻게 표시해야 할지 알려주는 헤더이다. 

inline인 경우 웹페이지 화면에 표시되고, attachment인 경우 다운로드된다. 

Content-Disposition: inline
Content-Disposition: attachment; filename='filename.csv'

다운로드되길 원하는 파일은 attachment로 값을 설정하고, filename 옵션으로 파일명까지 지정해줄 수 있다. 

Location

300번대 응답이나 201 Created 응답일 때 어느 페이지로 이동할지를 알려주는 헤더이다. 

HTTP/1.1 302 Found
Location: /

위와 같은 응답이 왔다면, 브라우저는 / 주소로 리다이렉트한다. 

Content-Security-Policy

다른 외부 파일들을 불러오는 경우, 차단할 소스와 불러올 소스를 여기에 명시할 수 있다. 

하나의 웹 페이지는 다양한 외부 소스들을 불러온다. 이미지도 불러오고, script 태그로 자바스크립트 파일들도 불러온다. 폰트나 스타일, 아이프레임도 불러온다. 

하지만 해커들에 의해 원하지 않는 파일을 불러오게 될 수도 있다. 

악성코드가 담겨있는 파일이라면 문제가 발생할 것이다. XSS 공격 같은 것이 하나의 예시이다. 

이럴 때, Content-Security-Policy로 허용할 외부 소스만 지정할 수 있다. 

Content-Security-Policy: default-src 'self'
Content-Security-Policy: default-src https:
Content-Security-Policy: default-src 'none'

self로 지정하면 자기 도메인의 파일들만 가져올 수 있다. www.abc.com에서는 www.abc.com/logo.jpg를 가져올 수 있지만, www.def.com/logo.jpg는 가져올 수 없다.  

https://로 지정하면 https를 통해서만 파일을 가져올 수 있게 된다. 

'none'으로 지정하면 가져올 수 없다. 

default-src는 모든 외부 소스에 대해 적용된다. 각각 따로 지정할 수도 있다. 두 개나 세 개로만 추려서 지정할 수도 있다. 

Content-Security-Policy: font-src 'self'; script-src https://www.zerocho.com 'unsafe-inline'; 
img-src 'self'; style-src 'self' 'unsafe-inline'; object-src 'none'

font-src, script-src, img-src, style-src, object-src 등이 있고, 소스 옵션으로는 도메인이나, https://, 'unsafe-inline'(인라인 태그 허용), 'unsafe-eval'(eval 함수 허용) 등이 있다. 

옵션은 매우 다양하므로 아래 링크를 참고해보자. 

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

이 외에도 다양한 응답 헤더들이 있다. 오늘은 유명한 응답 헤더들만 정리해보았다. 

다음 포스팅에서는 쿠키와 캐시 헤더에 대해 알아보도록 하자. 

2021.05.28 - [CS/네트워크] - [네트워크] 알아두면 좋은 HTTP 쿠키, 캐시 헤더

이 포스팅은 아래 링크를 참고했습니다. 

https://www.zerocho.com/category/HTTP/post/5b4c4e3efc5052001b4f519b

앞 내용을 잠시 복습해보자면, 서버의 역할은 클라이언트로부터 요청을 받아 응답을 보내는 것이다. 요청과 응답은 메세지 형식으로 오고, 이게 바로 HTTP 메시지! HTTP 메시지는 시작줄, 헤더, 본문으로 구성되어 있다. 

HTTP에 대해 알고싶다면, 아래 포스팅을 클릭해보자. 

https://dolphinsarah.tistory.com/38

HTTP 메소드에 대해 알고 싶다면, 아래 포스팅을 클릭해보자. 

https://dolphinsarah.tistory.com/39

이번 시간에는 헤더에 대해 알아볼텐데, 헤더 종류가 매우 많기 때문에, 알아두면 유용한 HTTP 공통 헤더와 요청 헤더에 대해 먼저 알아보도록 하자. 

헤더는 개발자도구(F12)의 네트워크 탭에서 확인할 수 있다! 

공통 헤더 

요청과 응답 모두 사용되는 헤더이다. 

Date

HTTP 메시지가 만들어진 시각이다. 자동으로 만들어진다. 

Connection

HTTP/2를 사용하지 않는다면 보통 HTTP/1.1을 사용한다. 

Connection은 기본적으로 keep-alive로 되어 있는데 사실상 아무런 의미도 없다. 

HTTP/2에서는 아예 사라져버렸다. 

Cache-Control

매우 중요하고, 꼭 알아둬야 하는 헤더이기 때문에 아래 포스팅에 따로 정리했다. 

2021.05.28 - [CS/네트워크] - [네트워크] 알아두면 좋은 HTTP 쿠키, 캐시 헤더

*Content 시리즈는 엔티티 헤더라고 불린다. 

Content-Length

요청과 응답 메시지의 본문 크기를 바이트 단위로 표시해준다.

메시지 크기에 따라 자동으로 만들어진다.

Content-Length: 52

Content-Type

컨텐츠의 타입(MIME)과 문자열 인코딩(UTF-8 등)을 명시할 수 있다. 

조금 뒤에 나오는 Accept 헤더, Accept-Charset 헤더와 대응된다. 

 위의 예시 헤더는 현재 메시지 내용이 text/html 타입이고, 문자열은 utf-8 문자열임을 알려준다. 

Content-Language

사용자의 언어를 뜻한다. 요청이나 응답이 무슨 언어인지와는 관련 없다. 

예를 들어, 한국인에게 일본어를 가르치는 사이트일 경우, 페이지 언어는 일본어일지라도

Content-Language는 ko-KR일 수 있다. 

Content-Encoding

Content-Encoding은 컨텐츠의 압축된 방식이다. 

응답 컨텐츠를 br, gzip, deflate 등의 알고리즘으로 압축해서 보내면, 브라우저가 알아서 해제해 사용한다. 

이외에도 다양한 압축 알고리즘이 존재한다. 컨텐츠의 용량이 줄어들기 때문에 압축을 권장한다. 

요청이나 응답 전송 속도도 빨라지고, 데이터 소모량도 줄어들기 때문에 가능하면 압축해두는 게 좋다. 

요청 헤더

Host

서버의 도메인 네임이 나타나는 부분이다. (포트 포함) 

Host 헤더는 반드시 하나가 존재해야 한다. 

User-Agent

Host보다 더 유명한 헤더는 User-Agent다. 

현재 사용자가 어떤 클라이언트(운영체제와 브라우저 같은 것)를 이용해 요청을 보냈는지 나온다. 

아래의 이미지를 보면 내 클라이언트가 무엇인지 알 수 있다. (나는 LG gram 크롬으로 접속했다)

물론, User-Agent를 믿어서는 안된다. 헤더를 변경할 수도 있으니까. 

하지만 대부분의 사람들이 User-Agent를 조작하지 않고 그대로 보내기 때문에,

User-Agent 헤더를 활용해서 접속자 통계 등을 내곤 한다. 

또, 이를 활용해 IE로 접속한 사람들을 찾아내고, IE는 지원하지 않으니 크롬으로 접속해달라는 메시지를 표시하기도 한다. 

Accept

이제, Accept 시리즈를 알아보자. 

Accept 헤더는 요청을 보낼 때 서버에, 이런 타입(MIME)의 데이터를 보내줬으면 좋겠다고 명시할 때 사용한다. 아래처럼 콤마로 여러 타입을 동시에 적어줄 수도 있다. 

위와 같이 요청 헤더를 보낸다면, html 형식, xhtml+xml 형식 등등의 응답을 처리하겠다는 뜻이다. 

Accept 시리즈라고 한 것은, Accept-Encoding, Accept-Charset, Accept-Language 등도 있기 때문이다. 

공통 헤더의 Content 시리즈와 대응된다. 

Accept로 원하는 형식을 보내면, 서버가 그에 맞춰 보내주면서 응답 헤더의 Content를 알맞게 설정할 것이다. 

Accep-Charset: utf-8
Accept-Language: ko, en-US
Accept-Encoding: br, gzip, deflate

Charset은 문자 인코딩(UTF-8 등)을 명시하는 부분이고, Language는 원하는 언어, Encoding은 원하는 컨텐츠 압축 방식이다. 

뭘 적어야할지 모르겠다면 *를 적거나, 그냥 브라우저가 알아서 설정해서 보내는 Accept를 사용하면 된다.

Authorization

Authorization 헤더는 인증 토큰(JWT든, Bearer 토큰이든)을 서버로 보낼 때 사용하는 헤더이다. 

API 요청 같은 것을 할 때 토큰이 없으면 거절당하기 때문에, 이때 Authorization을 사용하면 된다. 

Authorization: Bearer XXXXXXXXXXXXX

보통 Basic이나 Bearer 같은 토큰의 종류를 먼저 알리고, 그 다음에 실제 토큰 문자를 적어 보낸다. 

Origin

POST 같은 요청을 보낼 때, 요청이 어느 주소에서 시작되었는지를 나타낸다. 

여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 문제가 발생하기도 한다. 

Referer

이 페이지 이전의 페이지 주소가 담겨 있다. 

이 헤더를 사용하면 어떤 페이지에서 지금 페이지로 들어왔는지 알 수 있기 때문에 애널리틱스 같은 곳에 많이 사용된다. 재밌는 사실은, Referer은 오타다. Referrer가 표준어인데 실수로 Referer로 만들었다고 한다. 

다음 포스팅에서는 응답 헤더에 대해서 알아보자. 

2021.05.28 - [CS/네트워크] - [네트워크] 알아두면 좋은 HTTP 응답 헤더

이 포스팅은 아래 링크를 참고하였습니다. 

https://www.zerocho.com/category/HTTP/post/5b3ba2d0b3dabd001b53b9db