常連

### 前提・実現したいこと

React+ReduxでSPAアプリケーションを開発中です。
ページのリロード（f5キー）時に状態が初期化されるのを防ぎたいのですが、中々いい案が思い浮かびません。
イメージ的にはリロードがされた時に発火するような処理を作りたいです。
どなたかご教授お願いいたします。

React+Reduxでリロード時も状態維持

最近SPAについて勉強しています。

SPAでは、クライアントサイドレンダリングが基本だと思います。
Vue.js や React を用いてビュー部分をブラウザにわたし、サーバーサイドではAPIのみを提供しページの構築を行うと思います。

例えば、「管理者なら管理用メニュー、一般ユーザーなら普通のメニューを表示する」のようなロジックを例にすると、ビュー（ここでは Vue.js を使用すると仮定）では次のような実装が考えられると思います。

```html
<div v-if="userType === 'user'">
   	
</div>
<div v-if="userType === 'admin'">
	
</div>
```

善良なユーザーが使う分には問題無いと思いますが、悪意あるユーザーがコンソールで「userType = 'admin';」などと入力しただけで管理用メニューが表示されてしまいます。

また、そうでなくても表示されないにしろ、HTML/JSに管理用メニューの名前、及びAPIのアクセス先が書いてあるため、API側で何かしらの認証処理をするという前提があったとしても、管理用メニューにどういうものがあるのかを見られてしまうのは脆弱性につながりかねません。

このような点に関してどのような対処をするのが一般的なのでしょうか？


[追記]
皆さん、回答ありがとうございます！
質問の仕方が悪く、自分の伝えたい本質を書くことができていませんでした。

認証周りの話というよりはユーザー(ブラウザ)がコンポーネントに対する操作が可能ということに疑問を持っています。

コンソールからコンポーネントに渡すデータを変えればそのコンポーネントの挙動を変更することとが可能だと思います。

例えば入力フォームを作る場合に特定の条件のユーザーにはフォームを表示しないといったケース、
具体的にはアンケートでユーザーの会員情報で性別が女性の場合は化粧品についてのアンケートも追加で表示させるケースを考えたいと思います。

サーバーサイドレンダリングであればサーバー側でユーザーの性別を見て生成するHTMLを変更できます。

クライアントサイドレンダリングの場合は一旦全て送り、ユーザー側で非表示にさせるといった処理が考えられそうです。

ここでユーザーがコンソールから性別データをいじった場合、男性なのに化粧品のアンケートを表示させる、女性なのに化粧品のアンケートを表示させない のようなことが可能になってしまう気がします。

回答でいただいたコードスプリッティングなどで対応はできそうですが、こんな些細なものごとにいちいち分割しているとは思えません。

[追記2]
もちろんこれはSPAに限らずJavascript自体のリスクではあると思いますが、
サーバーサイドレンダリングの場合、JSは「見た目の操作」にのみ使われてることが多いと思います。
SPAではややロジックも担当している印象を受けたためこのような質問をしました。

ユーザーからの挙動変更が可能なリスクがある中でどのような策がなされているのか、あるいはなすべきなのか 教えていただきたいです。

SPA・クライアントサイドレンダリングはセキュリティ的に安全なのでしょうか？

### 前提
Next.jsでAPIを使ってデータを取得しています。
ページ表示時サーバーサイドでデータを取得
クライアントサイドでの通信は環境変数を使用してAPIキーを指定している

### 実現したいこと
クリックされた時に
条件を変えてクライアントサイドで再度API通信をした際にAPIキーが見えてしまうので隠したい。

最初はサーバーサイドでAPI通信をしているので問題ないですが、条件を変えて再度API通信をするとクライアントサイドの処理になるためAPIキーがディベロッパーツールで見えてしまう。

**クリックイベントでクライアントサイドではなくサーバーサイドで処理を実行させる方法があるのでしょうか？
それが不可の場合APIキーを扱う際は通常どのように管理するのでしょうか？**

### 発生している問題・エラーメッセージ
ボタンをクリック→再度API通信をして条件に合うデータを再取得
クライアントサイドでの処理になるためAPIキーがディベロッパーツール上に表示される

### 該当のソースコード

index.js
```
import axios from 'axios';
import { useEffect, useState } from 'react';

export async function getServerSideProps() {

    let dataes;
    
    await axios.get('http://webservice.recruit.co.jp/hotpepper/middle_area/v1/?format=json&key=*****')
    
    .then(nn=>dataes=nn.data.results.middle_area)
    
    .catch(error=>console.log(error))

    return {props:{dataes}}
        
    }

            
    

function Main({dataes}) {
    
    const[state,setstate]=useState([])

    // 条件を変えるためstateでデータを管理
    useEffect(()=>{
        setstate(dataes)
    },[dataes])

// ボタンがクリックされた際に再度API通信をして新たにデータを取得
    const pp=()=>{
        const url='https://api-cors4544545454.herokuapp.com/http://webservice.recruit.co.jp/hotpepper/large_area/v1/?format=json&key='+process.env.NEXT_PUBLIC_APIKEY;
         axios.get(url)
    
        .then(nn=>setstate(nn.data.results.large_area))
        
        .catch(error=>console.log(error))
    
    }

    return(
<>
 {state.map((i,index)=>(
    <div>
        <p>{i.name}</p>
        <button onClick={pp}>押下</button>
    </div>
     ))}
    
    </>

    )
}

export default Main;
```

### 試したこと
クライアントサイドでAPI通信をするときは環境変数を使用

**クリックされた時にクライアントサイドではなくサーバーサイドで処理を行う方法があるのでしょうか？**

### 補足情報（FW/ツールのバージョンなど）
Next.js   ver 12.1


Next.js APIキーを隠したい

お世話になっております

Firebase Authenticationを使おうと思っているのですが、
セキュリティについて気になる点があったので、ご教授いただきたいです

構成はクライアント(SPA)とAPIサーバー(Firebase admin)として、
ユーザーの認証は以下のような流れで公式に書いてあります

1 クライアントでトークンを取得し, APIサーバーに送信
2 APIサーバーはverifyIdToken(またはVerifyIDTokenAndCheckRevoked)でトークンを検証

[公式URL: IDトークンを検証する ](https://firebase.google.com/docs/auth/admin/verify-id-tokens?hl=ja)

このトークンはセッション管理に使用されていると思われますが([参考URL](https://ritou.hatenablog.com/entry/2020/01/08/070000))、
トークン自体はブラウザのindexedDBに保存されています

SPAのユーザー認証でlocalStorageに入れるとXSSのリスクがあるというのは有名です
Cookie(httponly + secure)とサーバーサイド側のセッション管理をするのが現状は無難という認識ですが、

Firebase Authenticationについて、以下の認識で合っていますでしょうか？

1 セッション管理はしている
2 しかし、indexedDBなのでXSSのリスクはある(localStorageで取り上げるよくある問題)

他にもセキュリティリスクがあったらぜひ教えていただきたいです
お手数ですが、よろしくお願いいたします

追記
ご指摘をいただいて、今回の質問はXSSではないかもしれません

今回の質問は、ユーザーの入力値などでJavaScriptが実行されるものではなく、
scriptタグなどで第三者のJSを実行している時、その第三者のJSが改ざんされ、localStorage/indexedDBの値を抜かれるというものです

こちらの記事を読んで気になりました
https://techracho.bpsinc.jp/hachi8833/2019_10_09/80851

そうそうあることではないと思いますが、このあたりを意識する場合、Firebase Authenticationで何か対応されていることはありますでしょうか

Firebase Authenticationのセキュリティについて(トークンとXSS)

現在YouTubeのAPIを用いてWEBアプリケーションを作成しているものです。

実際にアプリケーションを公開したいのですが、可能であればJSに含まれるAPIキーを表示しないように公開したいと考えています。現在はHTMLファイルにベタでJSを記述しており、検証ツールから確認するとAPIキーを含んだソースが丸裸です。

gitにもAPIキーを***に置き換えてアップしているので、gitのデモページでは動作できない状態です。

・検証ツールからAPIキーを閲覧できないようにしたい。
・可能であればAPIキーを暗号化などしつつ、gitのデモページで動作させたい。

上記2点に関して、何か良い解決策がありましたら教えていただきたいです。

JavaScriptに記述したAPIキーを閲覧できない状態にしたい。

### 実現したいこと
SPAにログイン機能を実装する

### 前提
トークンベース認証とセッションベース認証について様々な意見を見た中で、SPAでは頻繁にAPIリクエストを送る関係でトークンベースが使われている（毎回認証が必要なくなる）という結論に達した。
そのため、JWTを使用して認証サーバーの構築を進めていきたい。

### 疑問
一般に
・アクセストークンは期限を短くする
・リフレッシュトークンは期限を長くする
したがって、アクセストークンの漏洩等のリスク低減になりうる。
という記事があり、それは理解できた。
ただ、ブラウザでセッションを管理するとなると現状CookieにhttpOnly属性をつけて保存するのがセキュリティ的にましだと考えたのですが、その方法だとどちらも毎回通信時にCookieを送る＝漏洩の危険性に関しては同等になりませんか？
リフレッシュトークンの運用方法についてはどのように実装すれば良いのでしょうか？


SPAにおけるトークンベースのトークン管理について

### 開発環境

|ツール|バージョン|
|:--|:--:|
|Laravel|8.68.1|
|Vue.js|2.6.14|

その他ツール
componentでのHTTPクライアント : axios
### エラー発生手順
LaravelとVue.jsでSPAの掲示板的なWEBサービスを作成しています。
画面はホーム画面と、個別画面の２つがあります。

ホーム画面には、タイトル一覧が並んでいます。
クリックすると、コメントができる個別画面に遷移します。

ここで、遷移したすぐの状態ならコメントができるのですが、
個別画面から、ブラウザをリロード（更新）をした後にコメントをすると、419エラーが発生します。
componentからのpostはaxiosでaxios.postを使用しています


```
Request Method: POST
Status Code: 419 unknown status
```

### 考えられること
csrf-tokenの不一致
ホーム画面にアクセスした時に、以下のようにheadタグにcsrf-tokenが作成され、
ページ遷移後もこの値は変わりません
```
<meta name="csrf-token" content="dfdasfaaaq06jOqqPeFm11T2o3rDyBPnea1E8t">
```
しかしブラウザのリロード（更新）をすると、このcsrf-tokenの値が変化しました。

ホーム画面で更新して変化した場合、遷移後の個別画面でも問題なくPOSTのAPIを叩くことができましたが、
遷移後の個別画面で更新して変化した場合、POSTのAPIを叩くと419エラーが発生します。
このtokenの参照や照合が怪しいと調べているのですが、解決方法が分からず。

cookieやsession、token周辺の知識が乏しいため、どうかご教授いただけないでしょうか。
何卒宜しくお願いいたします。

### 追記
axios.postを使用しています
ルーティングはapi.phpで、ミドルウェアにapiを設定しています。
さらに、app/Http/Kernel.php の $middlewareGroups にて
App\Http\Middleware\VerifyCsrfToken　を設定していました。

これを外せば、エラーは無くなりPOSTモ通りましたが、CSRFに対して脆弱性が残ってしまいます。
その画面でリロードをせず他の画面から遷移してくればPOSTは通るので不思議です

判明したこととして、エラーになったときはCookiesで
Response Cookiesの　XSRF-TOKEN がありませんでした。
また、エラー1回目のPOSTの時に　testapuri_session　の値もrequestとresponseで違っていました。

###### リロードせずに、POSTが通るとき
・Request Cookies
|Name|value|Domain|...etc|
|:--|:--:|
|XSRF-TOKEN|AAAAAA|127.0.0.1|...|
|testapuri_session|BBBBB|127.0.0.1|...|

・Response Cookies
|Name|value|Domain|...etc|
|:--|:--:|
|XSRF-TOKEN|CCCCCC|127.0.0.1|...|
|testapuri_session|BBBBB|127.0.0.1|...|

###### リロードして、エラーになるとき
1回目、Response CookiesにXSRF-TOKENがない、sessionIdも違う
・Request Cookies
|Name|value|Domain|...etc|
|:--|:--:|
|XSRF-TOKEN|AAAAAA|127.0.0.1|...|
|testapuri_session|BBBBB|127.0.0.1|...|

・Response Cookies
|Name|value|Domain|...etc|
|:--|:--:|
|testapuri_session|DDDDD|127.0.0.1|...|

2回目以降、Response CookiesにXSRF-TOKENがない、sessionIdは同じになる
・Request Cookies
|Name|value|Domain|...etc|
|:--|:--:|
|XSRF-TOKEN|AAAAAA|127.0.0.1|...|
|testapuri_session|DDDDD|127.0.0.1|...|

・Response Cookies
|Name|value|Domain|...etc|
|:--|:--:|
|testapuri_session|DDDDD|127.0.0.1|...|


###### エラーになった時の、httpリクエストとレスポンスなどの情報です
```ここに言語を入力
URL: http://127.0.0.1:8000/testpage/1

# General
Request URL: http://127.0.0.1:8000/api/testpost
Request Method: POST
Status Code: 419 unknown status
Remote Address: 127.0.0.1:8000
Referrer Policy: strict-origin-when-cross-origin

# Response Headers
Access-Control-Allow-Origin: *
Cache-Control: no-cache, private
Connection: close
Content-Type: application/json
Date: Tue, 30 Nov 2021 12:54:45 GMT
Date: Tue, 30 Nov 2021 12:54:45 GMT
Host: 127.0.0.1:8000
Set-Cookie: testapuri_session=zMg8dCSHvH4jw5DzxHbva8PIiNDGS2PAqy6gNjvj; expires=Tue, 30-Nov-2021 14:54:45 GMT; Max-Age=7200; path=/; httponly; samesite=lax
X-Powered-By: PHP/7.4.13
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 53

# Request Headers
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: ja,en-US;q=0.9,en;q=0.8
Connection: keep-alive
Content-Length: 17
Content-Type: application/json
Cookie: XSRF-TOKEN=eyJpdiI6IlNSemI4N2...長いので省略; testapuri_session=eyJpdiI6Im4vbjQ0KzAya0JZYmVV...長いので省略
Host: 127.0.0.1:8000
Origin: http://127.0.0.1:8000
Referer: http://127.0.0.1:8000/testpage/1
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="96", "Google Chrome";v="96"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "macOS"
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.55 Safari/537.36
X-Requested-With: XMLHttpRequest
X-XSRF-TOKEN: eyJpdiI6IlNSemI4N21...長いので省略

# エラー
{message: "CSRF token mismatch.", exception: "Symfony\Component\HttpKernel\Exception\HttpException",…}
exception: "Symfony\Component\HttpKernel\Exception\HttpException"
file: "/Users/username/Desktop/testProject/laravel-app/vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php"
line: 389
message: "CSRF token mismatch."
```

LaravelとVue.jsの環境で遷移先でリロードした後にPOSTのAPIを叩くと419エラーになる

# 質問
SPA開発におけるAPI設計なのですが、何が良いのかわかりません。
特にGETメソッドのエンドポイントに関してです。

特定のクライアント用のAPIなので、汎用的なものではなく、ある程度、クライアントを意識したもので良いという前提があると思うので、
画面で必要な情報を全て返すAPIエンドポイントを用意してあげるのが良いのでしょうか？

それとも、リソース単位のAPIをクライアントに提供して、クライアント側では必要に応じて、受け取った情報を用いて、計算、判断、加工などの処理を行ってもらうのが良いのでしょうか？

もしくは、「要はバランスだよね」おじさん的な感じになるのでしょうか！？

前提、ビジネスロジックはバック側に持たせるで良いと思うのですが、画面依存させないAPI(リソース単位のAPI)を提供しているとどうしても、フロント側でリソースAの情報の一部と、リソースBの情報の一部をそれぞれ組み合わせて、加工、判断、計算をしないといけないような場面が出てきてしまうと思っています。

例えば、ログインユーザーのロールがXYZというロールで、かつ、帳票が生成済みの場合であれば、ダウンロードボタンを表示、または、活性化させたいような場合、ユーザーリソースに含まれるロール情報と、帳票情報に含まれるステータスの両方をみて、ダウンロード可能かどうかをフロント側で判断しないといけないと思います。

EvansのDDD本にはアンチパターンとしてSmart UIなる表現がありますし、最近、ツイッター界隈ではフロントエンドはJSON色付け係に徹するべなる主張も見かけまして、SPA開発におけるAPIやフロントエンド側のStore設計はどうあるべきなのか、混乱してきたのが質問の背景になります！

※ EvansのDDD本にあるSmart UIのUIはViewとControllerの両方を含んだプレゼンテーション層を指していると解釈しています。

以下、メリデリ考えてみました。

## 画面単位のAPIエンドポイントを用意する場合
### 前提
画面単位のAPIエンドポイントとは、例えば、このteratailの個別質問詳細ページの場合だと、このページの表示に必要な情報（質問、回答一覧、関連質問一覧など）を１つのエンドポイントがまとめて返してくれるようなものをイメージして言っています。

### メリット
- フロント側は単に表示だけしていれば良く、バック側にビジネスロジックをすべて寄せることができる（あるとしても表示に関するフォーマットのロジックを持つくらい）

### デメリット
- 画面側の表示項目に変更が発生した場合など、API側の改修も必要になる
- APIが画面に依存するかたちになる
- 画面毎にAPIを叩く必要があるので、リソース単位のレスポンスと違って、既に取得済みのAPIレスポンスを使い回すことが出来ない
- ビジネスロジックがバックとフロントの両方に散らばってしまうことになる（フロント側に関しては、フロント側の各画面でビジネスロジックが散らばらないように、store側にビジネスロジックを寄せることで、複数の画面に同じロジックが散らばることは避けられる）
- 画面毎に対応する画面用のAPIエンドポイントを用意するので、似たような情報を含んだ情報を返すAPIエンドポイントが増えて気持ち悪い気がする
- 画面毎に対応する画面用のAPIエンドポイントを用意するので、APIエンドポイントが増えがち
- クライアントがブラウザー、アプリ、CLIと複数ある場合、クライアント毎に表示する情報が異なると思われるので、さらにAPIエンドポイントが増える

## リソース単位のAPIエンドポイントを用意する場合
### 前提
リソース単位のAPIエンドポイントとは、例えば、このteratailの個別質問詳細ページの場合だと、このページに対応した質問情報を返すエンドポイントがあったり、回答一覧を返すエンドポイントがあったり、関連した質問情報を返すエンドポイントがそれぞれ存在しているようなものをイメージしています。

### メリット
- 画面側の表示項目に変更が発生した場合、フロントが既にバックから受け取っているデータを用いて、計算、加工することでAPIの改修が不要になることもある
- 既に取得済みのAPIレスポンスをキャッシュして使い回すことができる場合がある（キャッシュして問題ないものに限る）

### デメリット
- フロント側で一部、ビジネスロジックを持つことが発生し得る。（独り言：リソース単位でフロントにレスポンス返すと、フロントでビジネスロジックを本当に持ち得えるのか？その処理はフロント側にあっても別に問題ないような処理だったりしないのか？つまり、ビジネスロジックであるのかどうか？ 改めて、ビジネスロジックとは何かの定義と具体例を挙げて、検討した方が良さそう）

## リソース単位のAPIエンドポイントと画面単位のAPIエンドポイントの両方を用意する？？？
メリデリ挙げてみて、両方のパターンの組み合わせを用意するのはどうなのだろうと思いつきました。
こういうのって、実際、やってたりするのでしょうか？

例えば、リソース単位のAPIを叩くのを基本としつつも、そのAPIでは取得出来ない画面固有の差分を取得するAPIエンドポイントを別途用意するみたいなイメージです。

## よくわかっていないけど、BFF ???
BFFがあまりなんだかよくわかっていないですが、リソース単位のAPIエンドポイントは用意して、フロントエンド側の個々の画面に必要な情報をまとめたレスポンスを返すAPIエンドポイントをBFFに用意する？

SPA(Single-page Application)