2025년 javascript 보안 정리

• JavaScript는 전 세계 모든 웹사이트에 거의 빠짐없이 사용되며, 현대 웹의 심장과도 같은 존재입니다. 
• 최근 SKT 해킹과 같은 심각한 보안 사고처럼 JavaScript 역시도 취약한 드로 인해 데이터 유출, 사이트 탈취, 사용자 신뢰 상실 등이 발생할 수 있어, 관련 보안방법을 정리해 보았습니다.
• 단순한 웹사이트를 만들든, 복잡한 기업용 애플리케이션을 개발하든, 보안은 개발 초기 단계부터 반드시 고려되어야 합니다. 개발이 완료된 후에 보안을 추가하는 것은 위험하며, 사후 대처 비용이 훨씬 큽니다. 미리 알고 대비해야 합니다.

 

대표적인 Javascript 공격기법

 

XSS

• XSS은 공격자가 웹 페이지에 악성 스크립트(JavaScript 등)를 삽입하여, 해당 페이지를 보는 사용자의 브라우저에서 실행되도록 하는 공격 기법입니다.
• 대표적인 XSS 사례는 악성 이메일에 자바스크립트를 삽입하여 사용자가 메일을 열람 시 XSS 실행되도록 하는 설정하는 것이다. XSS가 실행되면, 해커는 사용자의 이메일 세션 쿠키들을 탈취하고 사용자의 이메일 계정에 무단 접근이 가능합니다.

 

XSS 보안 대책

• 사용자 입력을 직접 DOM에 삽입하지 말고, 반드시 검증해야 합니다. DOMPurify와 같은 라이브러리를 사용하여 입력을 검증할 수 있습니다.

// 직접 검증
const userInput = document.getElementById('inputField').value;
const safeText = document.createTextNode("Hello " + userInput);
document.getElementById('output').appendChild(safeText);

// DOMPurify 사용
import DOMPurify from 'dompurify';
const cleanInput = DOMPurify.sanitize(userInput);

 

• innerHTML은 XSS 공격에 취약하므로, 텍스트 삽입 시에는 textContent나 createTextNode를 사용해야 합니다.

const commentDiv = document.createElement('div');
commentDiv.textContent = comment;
document.getElementById('comments').appendChild(commentDiv);

 

• CSP(Content Security Policy)는 웹 애플리케이션이 브라우저에 사이트에서 어떤 리소스(스크립트, 이미지, 스타일 등)를 허용할 것인지를 명시하는 보안 정책입니다. 이 정책으로 브라우저가 웹 페이지를 렌더링 할 때 허용되지 않은 리소스의 로딩이나 실행을 차단함으로써 XSS와 같은 공격을 막을 수 있습니다.

Content-Security-Policy: script-src 'self';
// 위 설정은 페이지에 포함된 모든 인라인 스크립트와 외부 CDN을 차단하고, 현재 도메인에서 로드된 스크립트만 허용합니다.

Content-Security-Policy: script-src 'self' https://trusted.cdn.com;
// 이 설정은 자체 서버 + 신뢰하는 CDN에서만 스크립트를 허용하고, 그 외 출처는 모두 차단합니다.

 

• eval() 및 Function 사용들은 의의 코드를 실행할 수 있어 보안 위험이 있습니다. JSON 파싱 시에는 JSON.parse()를 사용해야 합니다.

try {
  const parsed = JSON.parse(userInput);
  console.log(parsed.name);
} catch (e) {
  console.error("Invalid input provided by user.");
}

 

Cross-Site Request Forgery (CSRF)

• CSRF는 인증된 사용자가 자신의 의도와 무관하게 원하지 않는 요청을 웹 애플리케이션에 보내도록 유도하는 공격입니다. 해커는 용자의 세션 쿠키, 인증 정보 등을 악용하여 민감한 요청(예: 송금, 비밀번호 변경 등)을 실행할 수 있습니다.
• 대표적인 CSRF 사례는 사용자가 인증된 세션을 유지하고 있을 때, 해커가 보낸 이메일을 통해 브라우저가 자동으로 위조된 요청을 보냄으로써 의도하지 않은 행위가 실행되도록 유도하여 토큰을 탈취하는 경우이다.

 

CSRF 보안 대책

• CSRF Token을 사용하여 요청의 진위 여부를 판단한다.
• 서버에서 요청의 Referer 또는 Origin 헤더를 확인하여 합법적인 출처에서 온 요청인지 검사한다.
• SameSite 속성을 Strict 또는 Lax로 설정하면, 타 도메인에서의 요청 시 쿠키가 자동으로 포함되지 않도록 한다.
  • SameSite는 웹 브라우저에게 "이 쿠키는 언제 전송되어야 하는가?"를 명시하는 HTTP 쿠키 속성입니다. 이를 통해 타 사이트에서 유입된 요청(크로스사이트 요청)에 대해 쿠키를 전송할지 말지를 제어할 수 있어, CSRF 공격 차단에 매우 유용합니다.

res.cookie('session_id', '123abc', {
  sameSite: 'Strict', // 또는 'Lax'
  secure: true,
  httpOnly: true
});

 

 

Insecure Direct Object References (IDOR)

• IDOR은 인증된 사용자가 직접 객체(리소스)에 대한 식별자(ID, 파일명 등)를 조작해, 권한이 없는 리소스에 접근할 수 있게 만드는 취약점입니다.
• 대표적으로 개발자가 사용자의 요청에 포함된 ID, fileId, userId 같은 값을 신뢰하고 검증 없이 그대로 처리하여 이로 인해 다른 사용자의 정보 탈취, 민감한 파일 다운로드, 계정 탈취 등 심각한 결과를 초래할 수 있습니다.

IDOR 보안 대책

• 리소스 접근 전에 반드시 해당 자원에 접근할 권한이 있는지를 확인한다.
• 예측 가능한 숫자 ID 대신 UUID 또는 해시화된 식별자 사용한다.
• SAST(정적 분석), DAST(동적 분석), Fuzzing 도구로 IDOR 취약점 탐지해본다.

Sensitive Data Exposure 

• 개인 식별 정보(PII), 인증 자격 증명(예: 비밀번호, 토큰), 지불 정보, 건강 정보 등 민감한 데이터가 암호화되지 않거나 잘못 보호되어 노출되는 보안 취약점을 의미합니다.
• 특히, 개발자에게는 중요한 API키 들이나 비밀번호와 같은 민감한 정보를 조심해야 한다.

 

Sensitive Data Exposure 보안 대책

• 비밀번호, API 키, 액세스 토큰 등을 JavaScript, localStorage, sessionStorage 등에 저장하지 말고 서버 측 환경변수로 API 키 보관한다.
• 사용자의 민감 데이터(이메일, 전화번호, 주민번호 등)는 엄격히 필요한 경우에만 서버에서 클라이언트로 전송한다.
• Token은 HttpOnly + Secure 쿠키로 관리하여 js 접근을 방지한다.

 

정기적인 보안 감사

• npm audit와 같은 도구를 사용하여 의존성의 취약점을 점검하고, 보안 취약점을 조기에 발견하고 수정해야 합니다.
  • npm audit는 package.json 및 package-lock.json에 정의된 의존성 트리를 스캔하여 알려진 취약점을 포함한 패키지를 찾아내고, 해당 취약점의 심각도, 영향, 해결 방법을 알려주는 명령어입니다.