Referrer-Policy の制限を強めると安全になるという誤解 | blog.jxck.io
Intro Referrer-Policy は、送信される Referer の値を制御することが可能だ。 このヘッダの副次的な効果をよく理解していないと、「no-referrer にして送らないのが最も安全だ」という誤解を生むことになる。 では、複数あるポリシーの中でどのような観点で、どのディレクティブを採用するのが良いのだろうか? 前提として前回の記事の「リクエストの出自をチェックすることは現代の実装のベースプラクティスである」という点を踏まえて考えてみる。 令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io https://blog.jxck.io/entries/2024-04-26/csrf.html Referer とアナリティクス Referer は、リクエストに対してその前のページの URL を送るところから始まった。 GET / H
Origin 解体新書
Web 技術解体新書 第一章 Origin 解体新書 Same Origin Policy とは Web において非常に重要なセキュリティモデルの 1 つだ fetch や XHR でリクエストを送信したときに、 CORS 違反で失敗したり、 Preflight という謎のリクエストが送信されたりして悩んだ経験があるかもしれない。これらは全て、ユーザを保護するために設けられた Same Origin Policy という制限を、ブラウザが遵守した結果なのだ。 本書はこの重要な Origin という概念について、そもそもなぜそんなものが必要なのかという背景や、それがユーザを保護するメカニズム、 JSONP はなぜ危険なのか、 Preflight が飛ぶ理由、 Service Worker など新しい API との連携、 Spectre によって発覚した脆弱性と CORP,COOP,COEP,
Script Error — Javascript Solution with Sample Code | Sentry
The Problem Script error. “Script error” is what browsers send to the onerror callback when an error originates from a JavaScript file served from a different origin (different domain, port, or protocol). It’s painful because even though there’s an error occurring, you don’t know what the error is, nor from which code it’s originating. And that’s the whole purpose of window.onerror – getting insig
CORS for Developers
This Note provides historical and instructional context for developers working with Cross-Origin Resource Sharing (CORS) and the CORS-mode of Fetch. this whole document needs references and terms linkified 1. Introduction One of the defining characteristics of a Web application is the way in which resources can link and communicate with each other. Over time, as browsers have evolved and become mo
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CORSの原理を知って正しく使おう | YouTube
