セキュリティヘッダ警察です！既に包囲されている！観念してヘッダを挿入しなさい！ - エムスリーテックブログ
【セキュリティチームブログリレー2回目】 こんにちは。エンジニアリンググループの山本です。 セキュリティチームは、エンジニアリンググループ全体のセキュリティを向上させるためのバーチャルチームなのですが、各プロダクト開発チームのサービスをチェックして、協力しながら全体のセキュリティを向上させていくのがミッションです。 そのお仕事の一環として「この部分、セキュリティヘッダが足りないから入れてください！」というやりとりを日常的に行なっています。 今日はこの「セキュリティヘッダ」というものが一体何なのか、今さら人に聞けないアレコレを取りまとめてみたいと思います。 セキュリティヘッダ警察の日常の図(もちろん冗談です) セキュリティヘッダ そもそもセキュリティヘッダとは？ 比較的安全なセキュリティヘッダ X-Content-Type-Options X-XSS-Protection Strict-Tr
ChatGPTをぬるぬるにする🐌Server-Sent Eventsの基礎知識
単方向通信であるということと、HTTP/1.1上で動作しているのが大きな特徴です。 また、HTTP上で動作することから、通信の互換性が高く、セキュリティモデルも使いまわせるので安心です。 どんな用途と相性がいいの？ 双方向通信がしたいわけでなければ、相性の幅がとても広いです。 今回の ChatGPT のような、GPT がトークンを生成するごとに送るケースはもちろん、通知の未読件数バッジの更新、ニュース速報の表示など、サーバからイベントを送りたい時ならなんでも使えます。 HTTP/1.1で動くカラクリ SSEはHTTPのレスポンスヘッダにContent-Type: text/event-streamを指定した上で動作します。 SSEが動く流れ クライアントがサーバーに HTTP/1.1 リクエストを送信し、イベントストリームに接続します。 サーバーは、Keep-Alive 接続を使用して、T
ブラウザキャッシュの仕組み
はじめに 最近Denoをよく触っており、DenoのSSRフレームワークであるFreshのミドルウェア・キャッシュについて調べている際にブラウザキャッシュのEtagヘッダが使用されており、気になったのでブラウザキャッシュの仕組みについて調べてみました。 Etagの正体 Etagとは、ブラウザキャッシュの仕組みの中で使用されるHTTPレスポンスヘッダーでリソースの特定のバージョンに関する識別子のことです。 Etagがあることでウェブサーバーは、コンテンツが変更されていない場合はレスポンス全体を再送する必要がないので、キャッシュがより効率的になる。 ブラウザキャッシュの設定について ブラウザキャッシュを設定する際に必要なHTTPレスポンスヘッダーはEtagを含めて以下の通りです。 Expiresヘッダー Cache-Controlヘッダー Last-Modifiedヘッダー Etagヘッダー そ
Content-Disposition の filename という地雷。 (1個の観点で17個の脆弱性を見つけた話) - ぶるーたるごぶりん
English ver: https://gist.github.com/motoyasu-saburi/1b19ef18e96776fe90ba1b9f910fa714#file-lack_escape_content-disposition_filename-md TL;DR 1つのブラウザ、1つのプログラミング言語、15個の { Web Framework, HTTP Client ライブラリ, Email ライブラリ / Web Service 等} で脆弱性を見つけました。 見つけた脆弱性は、全て 1つの観点で発見した (多分 50-80 くらいのプロダクトの調査をした)。 RFC の記載では、（かなりわかりにくく）この問題に対する要件が記載されており、WHATWG > HTML Spec の方はしっかりと書かれているといった状況にある。 この問題は、 Content-Dispo
Webブラウザ上で純粋なHTTPだけで単方向リアルタイム通信を可能にするHTTPのストリーミングアップロードが遂にやってくる - nwtgck / Ryo Ota
Web標準のHTTPクライアントfetch()でストリーミングしながらアップロードできるようになる。
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた？よし、それなら 200 を返しましょう。ページが存在しない？それなら 404 です。他のページにユーザをリダイレクトしたい？ 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳：HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200
HTTPステータスコード451(政治的な検閲)が正式に承認される
mnot’s blog: Why 451? draft-ietf-httpbis-legally-restricted-status-04 HTTPステータスコード451がIETFで正式に承認された。近いうちにRFCとしても発行される。 元ネタは、Ray BradburyのFahrenheit 451(華氏451)というタイトルの小説で、これはディストピアな検閲社会を描いている。 451の意味は、403(禁止/権限がない)と似ているが、正確な意味は、ドラフトを引用すると、以下の通り。 このドキュメントはサーバーオペレーターが、あるリソース、あるいはあるリソースを含むリソース群に対し、閲覧を検閲するよう法的な命令を受け取った時に使うHypertext Transfer Protocol(HTTP)ステータスコードを規定するものである。 このステータスコードは、法律や一般大衆の雰囲気がサーバー
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べたAPIOAuthWeb TL;DR HTTP でトークンを利用した認証・認可をする手法として RFC 6750 がある OAuth に限らず、トークンを利用して認証・認可する機構の一部として Authorization: Bearer ヘッダを使うことができる 使い方について詳しくはこの記事の下のほうに書いた 要求 トークンを利用した認証・認可機構を持つ API を作りたい クライアントがトークンを HTTP リクエストに含めて送信し、サーバはトークンを検証してリソースへのアクセスを許可したい Authorization: Bearer トークン ヘッダでトークンを送る API あるよね、ああいうやつ 疑問 Authorization: Bearer ヘッダは OA
HTTP/2のRFCを読んだ感想
はじめに 私は自ら「串職人」と名乗るほどウェブの(つまりHTTPの）Proxyサーバが好きで、もう10年以上もプロキシサーバを作り続けています。このブログの主題であるクラウド型WAF、Scutumもそのひとつです。そもそもプロトコルとしてのHTTPが好きです。ウェブの裏側に、とてもシンプルな、テキストベースのHTTPプロトコルが活躍しているということが私の串職人としての出発点です。 HTTP/2が出た 先日、ついにHTTP/2が出ました。 数年前から、「SPDY」などのキーワードに代表される次世代のHTTPが模索されていることは何となく知っていましたが、どうもGoogleのような非常に大きいトラフィックを処理している組織が主導しているもので、一般の開発者やウェブの利用者にとってそれほど魅力的なものではなさそうだな、という印象を抱いていました。 サーバ側を作っているのもGoogle、ブラウザ
21世紀のエンジニアのためのHTTP/2入門 | κeenのHappy Hacκing Blog
第3会FRESH勉強会で発表予定のスライド。HTTPについて詳しくない人のために HTTPの概要から先日RFC化されたHTTP/2の新機能、使いどころを解説します。
Studying HTTP
RFC(Request For Comments) 2616をはじめとした、HTTP(Hypertext Transfer Protocol)に関する文献などを紹介し、HTTPやWWW(World Wide Web)に関連する技術についての知識を深めるためのサイトです。About [Studying HTTP] 当サイトは、RFC 2616をはじめとした、HTTPに関する文献などを紹介し、HTTPやWWWに関連する技術についての知識を深めるためのサイトです。 当サイトを初めてご利用になる方は、Studying HTTP : Helpをお読みいただき、記述の内容にご同意の上、ご利用下さい。 2014.11.26 更新 当サイトへのご連絡は、現在メールのみとなっております。 Main Contents HTTP Status Code HTTP/1.1仕様書などで定義されているHTTPステータ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
知っているようで知らないWebサーバアーキテクチャ
「HTTP/2」がついに登場！ 開発者が知っておきたい通信の仕組み・新機能・導入方法