자바스크립트 버전: ECMAScript(ES)자바스크립트에도 여타 프로그래밍 언어와 같은 버전이 존재자바스크립트 버전: 자바스크립트도 자바나 다른 언어와 같이 ECMAScript으로 매년 새 표준이 등장자바와 달리 프로그램 실행을 위한 엔진 버전이 유저들이 쓰는 웹 브라우저마다 달라 Transpiler 필요자바스크립트 변수 선언 방법변수 선언은 자바스크립트 버전인 ECMAScript 6 (2015) 이전에는 `var` 하나의 방법으로만 선언 ECMAScript 6 버전 이후로 변수 선언은 `let` 과 `const` 로 선언할 수 있다.`let`: 가변 변수 선언 시`const`: 불변 변수 선언 시var, let, const 비교 정리 재선언재할당스코프`var`oo함수`let`x: 방어o: 가변 변수블..
전체 글
자바스크립트는 함수형 프로그래밍 패러다임을 추구하며, 추가로 객체지향 프로그래밍 패러다임도 지원 자바스크립트의 핵심은 함수(함수형 프로그래밍 패러다임) 와 객체(객체지향 프로그래밍 패러다임)이다.자바스크립트 개발자가 제대로 개발하기 위해서는 함수형 프로그래밍에 대해 완전히 이해해야한다.물론 자바스크립트 개발자도 객체지향을 완전히 이해해야한다. (우테코 자바스크립트 과제에서 객체지향 강조)일급함수함수를 변수, 파라미터, 반환으로 사용될 수 있다.순수 함수Thread-Safe: No Side Effects ⊂ 참조 투명성순수 함수 특징참조 투명성(Referentially Trannsparent) : 함수가 외부 상태에 의존하지 않는다.같은 파라미터에 같은 반환값부수 효과 없음(No Side-Effects):..
CORS 등장 배경CSRF(유저 비의도적 요청) 부분 방지를 위한 웹 브라우저 정책웹 브라우저는 자바스크립트를 동작시키는 엔진을 갖고있어, 무궁무진한 작업 수행이 가능함과 동시에 해커가 자바스크립트를 통해 위험한 작업을 수행할 수 있는 무한한 가능성을 갖게 된기도 한다.보안 취약성의 거의 대부분은 웹을 통해 이루어지며, 최전선에 있는 웹 브라우저는 보안에 예민할 수 밖에 없다.해커는 유저가 웹 브라우저를 정상적으로 사용할때, 악의적인 자바스크립트 수행으로 타 서버를 공격할 수 있다.웹 브라우저는 그런 요청이 발생하더라도 웹 브라우저 자신이 최대한 방지할 수 있도록 정책들을 마련해놓았다.W3C는 가장 먼저 SOP라는 정책 표준을 도입하여 웹 브라우저에서 단단하게 방어를 하도록 했는데API호출이 사실상 필수..
✅ HTTPS웹 통신 내 요청, 응답에 대한 암호화HTTPS(HTTP Secured, TLS): 웹 통신 내 end to end 회선 보호SSL(Secure Sockets Layer) 혹은 TLS(Transport Layer Seucurity) 프로토콜을 통해 HTTP 보안 강화✅ HTTPS 목적요청을 보내고, 응답을 받는 두 주체(end to end)만 HTTP 요청 및 응답을 읽을 수 있게 암호화목적: MITM(Man In The Middle) 공격 방지심화 : MITM (Man-In-The-Middle) 공격 종류🔹스니핑(sniffing, 도청): Wireshark 를 통해 여러분의 모든 웹 서핑 패킷 도청 가능보안되지 않았다는 것은 AP;access pointer 와 연결된 컴퓨터 사이에 암호화..
Session웹 서버 내 저장 + 단, SESSION_ID는 웹 브라우저 내 저장 및 전송session은 웹 브라우저 쿠키에 저장하던 값을 웹 서버측에 저장하기 위해 별개의 저장소 DB가 필요오해하지말자! Session을 사용한다고, Cookie를 사용하지 않는건 아니다.웹 브라우저 내 Cookie에는 어떤 세션인지 알기 위한 ID값 저장 필요Session의 대표적인 예: 웹 브라우저로부터 쿠키로 SESSION_ID를 받아 해당 요청 유저의 정보 조회속도가 매우 중요: API 수천번의 호출마다 Session 조회 필요그래서 현업에서 메모리 기반 DB인 Redis를 많이 사용 -> 비용 이슈..(메모리는 언제나 비싸다), 확장성 이슈(비싼 인스턴스)Session 의 장점Cookie의 단점 = Session..
이 Storage는 Cookie, Session처럼 Stateful HTTP를 위한 기술은 아니다.✅ Storage와 Cookie의 목적 차이🔹Storage웹 브라우저 저장소 (Stateful Http를 위한 기술은 아니다.)유저에 의해 변경된 옵션 상태 등 -> 필요에 따른 조회가 필요할 때(진짜 저장소)마지막에 어떤 소셜 계정으로 로그인했는지 저장하고, 1년 뒤 로그인할 때 표시하여 알려주기🔹Cookie웹 서버에게 웹 브라우저가 매번 전달할 특정 정보를 위한 저장소(Stateful)로그인 인증 정보 등 -> 웹 서버가 매번 요청할 때마다 필요한 정보를 웹 브라우저에 넣어두고 전달받아 쓴다.만료시간이 필요한 정보는 cookie를 사용 [Storage와 Cookie구분하기]사용자가 방문한 페이지 저장..
✅ Cookie웹 서버의 제어 + 웹 브라우저 내 저장 및 전송- 웹 서버의 제어: Set-Cookie헤더를 통해 어떤 데이터를 쿠키로 쓸것인지, 유효시간 및 보안 설정✅ 쿠키 사용의 기준: Dmain + Path웹 브라우저가 쿠키를 웹 서버에게 전송하는 기준(전송할지, 말지) = 해당 쿠키를 어떤 요청에 보낼지모든 쿠키에는 도메인이 연결되어있다.같은 도메인이더라도 각 페이지마다 보내줘야하는 쿠키가 다르다. 예를 들어서 웹 브라우저에 아래와 같이 저장되어 있는 쿠키 리스트가 있다고 쳐보자1번 쿠키 : h1 = w1 (Domain: `a.com`, Path: `/`)2번 쿠키 : h2 = w2 (Domain: `a.com`, Path: `/user`)3번 쿠키 : h3 = w3 (Domain: `b.com..
✅ HTTP 는 Stateless Protocol이다.💡Stateless?🔹Stateless(불연속성): 무상태, 서버가 클라이언트의 상태를 보존하지 않음최소한의 자원으로 서버 유지를 가능하게함 (수억명의 트래픽(Concurrent Users)커버 가능) - Easier to scale, cache, and manage the service기본적으로 세션을 유지하지 않고, 서버는 Client specific세션 데이터를 저장하지 않기에 클라이언트는 끊임없이 자신이 누구인지 밝혀야한다는 것 -> JWT HTTP는 stateless 하게 설계되었으나 쿠키와 세션을 활용해서 stateful하게 사용할 수도 있다고 이해했다.✅ Stateful HTTP: Cookie & Session웹 서버는 웹 브라우저..
프록시를 사용하는 이유보안: IP 숨기기 혹은 프록시 서버를 방화벽으로 사용하기도 한다(프록시 방화벽)속도(캐시): 동일 요청이 들어오면 서버에 다로 접속할 필요가 없이 저장된 Cache 자원을 반환전송 시간 절약, 외부 트래픽을 줄여 네트워크 병목 현상도 방지 = 이는 서비스의 속도를 높여준다ACL: 사이트 접근 범위 정책 정의 (Proxy Server 에 접속할 수 있는 범위를 설정하는 옵션)Log/ Audit: 리포트, 모니터링(회사 내 직원의 인터넷/인트라넷 사용을 레포팅)지역 네트워크 제한 우회: 한국에서는 접속이 제한이 되는 사이트 (IP 검사로 한국에서의 접속임을 감지)이런 경우 프록시 서버를 사용하면 접속을 다른 나라로 우회proxy는 클라이언트측 Forward Proxy 와 서버측 Rev..