
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Chaos and Order</title>
      <link>https://www.youngju.dev/blog</link>
      <description>천천히 올바르게. AI Researcher &amp; DevOps Engineer Youngju&#39;s blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, and data engineering — plus mindset essays on confidence, routines, health, and sport psychology.</description>
      <language>ko</language>
      <managingEditor>fjvbn2003@gmail.com (Youngju Kim)</managingEditor>
      <webMaster>fjvbn2003@gmail.com (Youngju Kim)</webMaster>
      <lastBuildDate>Sun, 26 Jul 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.youngju.dev/tags/browser-security/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.youngju.dev/blog/architecture/2026-07-26-cors-error-actually-explained</guid>
    <title>CORS 에러, 서버를 고쳐야 하는 이유 — 브라우저 정책의 정확한 동작과 잘못된 해법들</title>
    <link>https://www.youngju.dev/blog/architecture/2026-07-26-cors-error-actually-explained</link>
    <description>CORS는 서버를 지키는 보안 장치가 아니라 브라우저가 스크립트에게 응답을 읽게 해 줄지 판단하는 정책입니다. 그래서 curl은 되고 브라우저만 막히며, 고칠 곳은 언제나 서버의 응답 헤더입니다. 프리플라이트가 발생하는 정확한 조건, credentials를 쓸 때 와일드카드를 못 쓰는 이유, Vary 헤더가 없어서 CDN 캐시가 오염되는 사고, 브라우저 에러 메시지별 원인 해독표를 정리했습니다. 프록시 우회가 정당한 경우와 아닌 경우, 개발할 때 브라우저 보안을 끄라는 조언이 왜 나쁜지, 그리고 CORS가 CSRF를 막아 주지 않는다는 가장 위험한 오해까지 다룹니다.</description>
    <pubDate>Sun, 26 Jul 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>web</category><category>cors</category><category>http</category><category>browser-security</category><category>api</category>
  </item>

    </channel>
  </rss>
