<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Waylog Blog · Security</title>
    <link>https://waylog.pages.dev/category/security</link>
    <description>Waylog Blog의 Security 카테고리에 속한 글 모음</description>
    <language>ko-KR</language>
    <lastBuildDate>Thu, 21 May 2026 13:50:29 GMT</lastBuildDate>
    <pubDate>Fri, 08 May 2026 00:00:00 GMT</pubDate>
    <generator>Next.js</generator>
    <atom:link href="https://waylog.pages.dev/category/security/rss.xml" rel="self" type="application/rss+xml"/>
    <item>
      <title>CORS 오설정이 만드는 보안 구멍: Origin 검증 실패 패턴과 프로덕션 방어 설계</title>
      <link>https://waylog.pages.dev/posts/cors-misconfiguration-origin-validation-production-security</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/cors-misconfiguration-origin-validation-production-security</guid>
      <pubDate>Fri, 08 May 2026 00:00:00 GMT</pubDate>
      <category>Security</category>
      <description>CORS 오설정은 조용하게, 치명적으로 침투한다 CORS(Cross-Origin Resource Sharing)는 처음 마주치는 순간 대부분 개발자에게 &quot;브라우저가 왜 요청을 막는 거지?&quot;라는 짜증으로 다가옵니다. 그래서 가장 빠른 해결책인 Access-Control-Allow-Origin: 를 붙이고 문제를 덮어버립니다. 그 순간 브라우저 콘솔의 에러는 사라지지만, 보안 구멍이 열립니다. 우리 팀은 스테이지 서버에서 정확히 이 실수를 저질렀습니다. 빠른 QA를 위해 Access-Control-A</description>
    </item>
    <item>
      <title>서드파티 스크립트 공급망 공격 방어 실전: SRI 해시·CSP 소스 화이트리스트·npm 의존성 감사로 CDN 오염 막기</title>
      <link>https://waylog.pages.dev/posts/subresource-integrity-supply-chain-attack-defense</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/subresource-integrity-supply-chain-attack-defense</guid>
      <pubDate>Sun, 12 Apr 2026 00:00:00 GMT</pubDate>
      <category>Security</category>
      <description>CDN이 신뢰할 수 없게 된 날: 공급망 공격은 이미 우리 곁에 있다 웹 서비스는 오래전부터 외부 CDN에서 jQuery, Bootstrap, Google Analytics를 불러왔습니다. 빠르고 편리했기 때문입니다. 하지만 우리 프론트엔드 개발자들이 그 편리함 뒤에 있는 위험을 진지하게 마주한 것은 2024년 Polyfill.io 사건 이후였습니다. 수십만 개의 웹사이트가 아무 의심 없이 불러오던 스크립트가 악성 코드를 포함한 채 배포되기 시작했습니다. 이 글은 서드파티 스크립트 공급망 공격의 </description>
    </item>
    <item>
      <title>OAuth 2.0 PKCE 흐름 완전 해부: SPA와 모바일 앱에서 Authorization Code를 안전하게 쓰는 법</title>
      <link>https://waylog.pages.dev/posts/oauth2-pkce-flow-spa-mobile-security</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/oauth2-pkce-flow-spa-mobile-security</guid>
      <pubDate>Fri, 06 Feb 2026 00:00:00 GMT</pubDate>
      <category>Security</category>
      <description>퍼블릭 클라이언트는 비밀이 없다, 그래서 흐름 자체가 방어선이어야 한다 OAuth 2.0을 처음 도입할 때 우리 개발팀은 단일 페이지 애플리케이션에 Implicit Flow를 적용했습니다. 당시 공식 문서들은 SPA에서 &quot;clientsecret을 안전하게 보관할 수 없으니 Implicit을 쓰라&quot;고 안내했고, access token이 redirecturi의 fragment로 바로 내려왔습니다. 토큰을 즉시 받을 수 있어 편했지만, 2026년 현재 이 방식은 OAuth Security BCP에 의해</description>
    </item>
    <item>
      <title>JWT 함정 모음: 알고리즘 혼동·클레임 검증 누락·토큰 탈취 대응까지 보안 설계 실전</title>
      <link>https://waylog.pages.dev/posts/jwt-claims-validation-pitfalls-none-algorithm</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/jwt-claims-validation-pitfalls-none-algorithm</guid>
      <pubDate>Tue, 03 Feb 2026 00:00:00 GMT</pubDate>
      <category>Security</category>
      <description>JWT는 편리하지만, 그 편리함이 정확히 공격 지점이 된다 JWT(JSON Web Token)는 2010년대 중반 이후 웹 서비스 인증 표준으로 자리 잡았습니다. 서버가 상태를 저장하지 않아도 되고, 마이크로서비스 사이에서 검증이 간단하며, 다양한 언어와 플랫폼에서 라이브러리가 풍부합니다. 하지만 &quot;편리하다&quot;는 인식이 정확히 보안 취약점의 시작점이 됩니다. 우리 팀이 핀테크 스타트업에서 API 게이트웨이를 설계할 때, QA 단계에서 스테이징 환경 JWT 검증 코드를 점검하다가 알고리즘 파라미터 검</description>
    </item>
    <item>
      <title>웹 인증 세션 보안: HttpOnly Cookie, Refresh Token Rotation, CSRF 방어를 함께 설계하기</title>
      <link>https://waylog.pages.dev/posts/auth-session-cookie-refresh-token-security</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/auth-session-cookie-refresh-token-security</guid>
      <pubDate>Sat, 27 Jul 2024 00:00:00 GMT</pubDate>
      <category>Security</category>
      <description>로그인은 토큰을 저장하는 문제가 아니다 웹 애플리케이션에서 인증은 자주 단순화됩니다. access token을 어디에 저장할지, localStorage가 편한지, cookie가 안전한지 같은 질문으로 시작합니다. 하지만 실제 보안은 저장 위치 하나로 결정되지 않습니다. XSS, CSRF, 토큰 탈취, 세션 고정, refresh token 재사용, 로그아웃 전파까지 함께 설계해야 합니다. 인증 세션은 사용자 경험과 보안의 균형입니다. 너무 자주 로그인하게 만들면 사용자는 불편하고, 너무 오래 유지하</description>
    </item>
  </channel>
</rss>
