令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
reminder-lintでFeature Flagsの削除漏れを防ぐ | CyberAgent Developers Blog
こんにちは、FANTECH本部の前田(@arabian9ts)です。 以前、マルチリージョンで稼働する内製Feature Flagsの実装で、Feature Flagsをどのように利用しているかをご紹介しました。 今回は、Feature Flags自体の運用をどうしているか？について、ちょっとした工夫を紹介します。 使わなくなったFeature Flagsを消し忘れると？ 削除を忘れると、大まかに次の課題が発生します。 コード上の認知負荷が上がる ネットワークI/Oが発生するFeature Flagsシステムの場合、システムパフォーマンスに影響する つまり、Feature Flags自体の運用にも配慮する必要があります。 また、Feature Flagsの管理システムと、クライアントとなるコードベースが分離されている場合だと、使われているフラグなのかを認識するのが大変になります。 管理方法
macOS で multipass やってみようぜ (v1.0.0+mac) - Qiita
multipass ってなに？ mutipass って入れてるのに multipath が多くヒットしてしまう。。。 VM Engine として hyperkit, Hyper-V, Virtualbox, KVM を使った Ubuntu LTS (Long Term Support) 専用インスタンス (VM) を爆速で作成するツール。 Ubuntu LTS on tap: cloud-init で初期化された Ubuntu のインスタンスを起動 Native hypervisor: 爆速で起動するよう Hyper-V, HyperKit, Virtualbox, KVM などの Native Hypervisor を使用 Up to date: Canonical から最新の Ubuntu Cloud イメージを自動取得しインスタンスを作成 Optimised guests: 各ハイパ
ぼくのかんがえたさいきょうのGo HTTPサーバー起動方法
これまで何度か HTTP Server の Graceful Shutdown について記事を書きました。 Go 言語で Graceful Restart をする Go 言語で Graceful Restart をするときに取りこぼしを少なくする Go1.8 の Graceful Shutdown と go-gracedown の対応 最終的に Go 1.8 で Server.Shutdown が導入され、この件は解決を見ました。 しかし、最近「あれ？本当に正しく Server.Shutdown 使えている？」と疑問に思い、少し考えてみました。 というか ↑ の記事もまだ考慮が足りない気がする。 ぼくのかんがえたさいきょうの Go HTTP サーバー起動方法 とりあえず完成形のコード。 package main import ( "context" "log" "net/http" "os
multipassのVM作成時にcloud-initでLXDをセットアップ · hnakamur's blog
2019-10-21 はじめに multipass ではVMの作成時に multipass launch の --cloud-init オプションで cloud-init を使って初期化を行えます。 LXD をセットアップする手順を試行錯誤したのでメモです。 参考資料 cloud-init の Modules のドキュメント Ubuntu 18.04 LTS の cloud-init の cc_lxd.py のソース cloud-initの設定ファイル例その1 まず apt の設定でURLを日本のミラーサイトにします。 zfs でループバックのストレージを 80GB で作成します。 LXD のストレージバックエンドを zfs にします。 LXDのブリッジをデフォルト設定で新規作成します。 #cloud-config locale: en_US.utf8 timezone: Asia/Tok
“脆弱性を突くような攻撃を防ぐ”だけではない「WAF」 「AWS WAF」の運用で現場が抱える課題
WAFで困るのは「直して」と言えないこと 清野隼史氏（以下、清野）：ここからはもうちょっと現場レベルまで踏み込んでいきます。その中でも特にWAFのところにフォーカスをしてエピソードを聞きたいなと思います。このトピックでは、AWSの運用で現場が抱えている課題みたいなところを聞きたいなと思っています。こちらも佐竹さんに聞いてもいいですか？ 佐竹陽一氏（以下、佐竹）：はい。「AWS WAF」もしくは「WafCharm」を使っているという視点で話します。先ほど臼田さんが「Security Hubを使っている方」というアンケートをして、半分ぐらいの方が手を挙げられたことに「そんなにいるの!?」とむしろちょっとビックリしています（笑）。 （一同笑） 「意識高!!」と思ったんですけど（笑）。こういう課題は、もしかしたら現場の方も持っていると思います。 セッションの1個目のところでBookLiveさんが「
タイムスタンプの精度を落とすときは切り捨てろ - methaneのブログ
とあるプロジェクトでナノ秒からミリ秒への変換で四捨五入してきた人がいて、時刻を扱うときは保存精度未満は切り捨てるべきというのが常識になっていないなーと思ったので。 2023-10-01 を、何年か表示する時に、2024年に丸める人はいないだろう。 13:45 が何時か表示する時も、13時と表示するだろう。（口頭で何時？と聞かれたら14時と答えるかもしれないけれど） つまり、ある精度で表した時刻は、実際には次のような半開区間を示しているのである。 2023-01-01 00:00:00 <= 2023年 < 2024-01-01 00:00:00 13:45:00.000 <= 13:45 < 13:46:00.000 そして、そう決めたからには一貫して同じように、指定精度未満は切り捨てというルールを維持しなければならない。秒以下は四捨五入で、とかやってはいけないのだ。 一貫しないと何が問題
アジャイル開発とデータベース設計 - 変化に対応するシンプルな実装のために必要なこと - Agile Journey
はじめまして。そーだい（@soudai1025）です。私は普段は技術コンサルティングや受託開発を請け負う合同会社HaveFunTechの代表として、また、予防治療の自社サービスを展開する株式会社リンケージのCTOという二足の草鞋を履き、日々、さまざまなWebサービスの開発に携わっています。 これまでの開発経験のなかで、データベース設計に関わるさまざまな問題に遭遇してきましたが、本稿ではとくに、アジャイル開発時に発生しやすい問題とその対処についてお伝えしたいと思います。開発の現場で目にしやすい実装におけるアンチパターンを示しつつ、アジャイルという指針を維持しながら、対処となるデータベース設計についてご紹介します。 会員登録のアンチパターンと処方箋 イージーな実装とシンプルな実装 Userと言う名の罠 拡張と破綻 データベースは変化に弱い 仕様変更とテーブル変更 Addで変化に追従する 正規化
HashiCorp、TerraformをフォークしたOpenTofuに対しコードの不正コピーを警告。OpenTofuは完全否定
HashiCorp、TerraformをフォークしたOpenTofuに対しコードの不正コピーを警告。OpenTofuは完全否定 HashiCorpは昨年（2023年）8月、Terraformを含む同社製品のライセンスを、商用利用に制限があるBusiness Source License v1.1（BSL1.1）に変更すると発表。これに反発し、ライセンス変更前のTerraformをフォークしたプロジェクトとしてLinux Foundation傘下で登場したのが「OpenTofu」です。 参考：Terraformのフォークが「OpenTofu」としてLinux Foundation傘下で正式ローンチ。OpenTFから改名 しかしHashiCorpはこのOpenTofuを歓迎するつもりはまったくなかったようです。 HashiCorpがOpenTofuにコードの不正使用を警告 HashiCorpは
新規プロダクト開発で API の統合テスト文化が根付いているっていう話（Golang） - Uzabase for Engineers
はじめに 新規プロダクトにおける API テストの重要性を理解してもらう 誰でも容易に信頼性の高いテストが書ける基盤づくり カバレッジ情報の見える化でテストを書くモチベアップ API テストの継続的なリファクタで負債と戦う チームメンバーとのコミュニケーションと協力 おわりに はじめに はじめまして！株式会社アルファドライブにてバックエンド開発をやっています コタ @sirogami_main です。 この記事は AlphaDrive Advent Calendar 2023 の最終日の記事です！ qiita.com 現在開発中の新規プロダクトではバックエンドのほぼすべての API に複数のテストがあり、API テスト数の合計は720件を超えています。これは私一人の力ではなくて、チーム内にテスト文化が根付いているのがすごい大きいです。 嬉しいことに今では「とりあえず API テストは書こう
JUnitの実行結果のXMLフォーマット | DevelopersIO
Jenkinsでは、JUnitのテスト結果からテスト件数や実行時間などを集計することが出来ます。この時、JUnitの実行結果はXML形式のファイルとして出力され、「JUnitのXMLファイル」などと呼ばれています。ところが、このXMLのフォーマットは、JUnitの公式フォーマットではありません。JUnit自体には実行結果をXML形式に出力する機能は実装されていないため、Ant, Maven, Gradleといったビルドツールによって出力されています。恐らくはAntが出力していたJUnitの実行結果のXMLフォーマットに、Eclipseなどの他のツールが対応していき、結果としてデファクトスタンダードとなったと思われます。 Jenkinsでは、デフォルトでJUnitのXMLを集計できるため、他のテストツールを使ってテストを実行した場合にも、JUnitのXML形式に変換すれば、簡単にJenkin
TokenでもCookieでもBearer vs Sender-Constrained の概念を覚えよう｜ritou
こまけぇ話は置いておいて、BearerとSender-Constrainedの話がHTTP Cookieのところでも出てきたよというお話なのですが、ここを少し補足します。このBearer vs Sender-Constrainedという用語が一番出てくるのがOAuthの文脈です。 文字で読みたい2分間OAuth講座 : (1) The Basic Concepts (2) Bearer and Sender Constrained Tokens - r-weblife Bearer Token : 第1回で説明した地下鉄の切符のようなトークン。所持していれば使えるので、他の人が拾っても使えます。 Sender Constrained Token : 利用者を制限するトークン。飛行機の搭乗券のように、利用者が指定されている、制限されているもの。 概念はこんな感じですが、実装方法は色々なものが
Goのerrorがスタックトレースを含まない理由 - methaneのブログ
Twitterでこんな記事を見かけたので。 zenn.dev ジェネリクスの件もそうですが、Goの言語設計は現実主義なのになにか特別なポリシーによるものだと宗教化されてしまって、ファンには勝手に崇拝されてアンチにはディスられがちだなーと感じます。 Goのエラー処理を改善する実験プロジェクトxerrorsがGo本体のerrorsにマージされた時、 errors.New() はスタックトレースを取得していました。しかしGo 1.13がリリースされる前に削除されました。 削除された理由の1つは、今までの errors.New() のパフォーマンスに依存していたコードの速度が低下しアロケーションが増えることです。 github.com しかし、これが理由だと今まで思ってたのですが、実際にはもう1つより重要な理由がありました。エラーのフォーマットです。エラーに複数のフォーマットを持たせようという提案
内部エラーと外部エラー、それからGoのerrorがスタックトレースを含まない理由の考察
TL;DR Goのerrorは外部エラーを表現するもので、利用者（ライブラリならアプリケーション開発者、アプリケーションならユーザー）に入力値や環境の不備を伝える目的で存在している 一方で、開発中のソフトウェアが思っていたのと違う挙動を示した場合、その調査にはソフトウェアの特性によって異なるツールを使い分ける必要があり、一筋縄では行かない 両者を分けて考えることで、よりよいエラーハンドリングへの議論が初めて進められると考える 背景 Goのerrorがスタックトレースを含まないことは度々Goの欠点として挙げられます。たしかに、一度作ってどこかにデプロイしたソフトウェアがバグっており、スタックトレースがないせいでその原因調査に手間取ったことは筆者も一度のみならず体験しています。 一方で、（しばしばベテランのプログラマから）エラーはノイズを含むべきではないと主張されることも少なくありません。 ２
CI/CD Test Night #7を開催しました！
こんにちは、SWETのCI/CDチームに所属している幸田（@ponkio_o）です。 2024/03/26（火）に弊社オフィス（渋谷スクランブルスクア）とオンラインのハイブリッドで CI/CD Test Night #7 を開催しました。 本記事では、当日の発表スライドを紹介していきます。 参加者の反応 当日の様子はTogetterにまとめを作成しているので こちら からご覧いただけます！ 当日の動画 YouTubeにて当日のアーカイブ動画を公開しています。 www.youtube.com 発表紹介 @ponkio_o「業務で役立つ…かもしれない？！GitHub Actions Tips 集」 最初の発表は私の「業務で役立つ…かもしれない？！GitHub Actions Tips集」でした。 speakerdeck.com GitHubとの相性がよく、便利なGitHub Actionsです
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
自動生成を活用した、運用保守コストを抑える Error/Alert/Runbook の一元集約管理 / Centralized management of Error/Alert/Runbook to minimize operational costs using automated code generation
コードを書く隙間を見つけて生きていく技術/Findy 思考の現在地
「時間がない」症候群、その傾向と対策
独りよがりのプラットフォーム / For Whom that Platform Runs
Interface naming convention -er vs. -or