ここにあなたが欠けているものがあります:)
Parse.com の REST/JavaScript キーは、「すぐに使える」ように設計されています。これらのキーでは、オブジェクト アクセス ルールや beforeSave 検証を回避することはできません。これを行うことができるのはマスター キーだけです。マスターキーを保護します。有用な類推は、公開鍵暗号化です。公開鍵を共有する必要がありますが、秘密鍵を保護する必要があります。
誰でもあなたのデータを変更できますか? はい、ただし許可した場合に限ります。ユーザーは他のユーザーに属するデータを照会できますか? はい。ただし、許可した場合に限ります。Parse には、データの整合性とセキュリティを確保する方法がいくつかあります。
1 つ目は、オブジェクトごとのアクセス許可です。Parse.com Web インターフェイスを使用して、a) オンザフライでクラスを作成できるかどうか、および b) 既存のクラスの CRUD 権限を設定します。アプリを保護するための簡単な手順の 1 つは、明示的に必要でないクラスのアクセス許可を無効にすることです。たとえば、バックエンドで作成され、エンド ユーザーが書き込み可能 (またはおそらく読み取り可能) である必要のないオブジェクト。
2 つ目は、アクセス制御リスト (ACL) です。ACL は各レコードに設定されます。レコードを読み書きできるユーザーまたはロールを指定します。ACL のないレコードは公開されます (すべてのユーザーが検索できます)。Sue が非公開にする必要があるレコードを作成する場合は、ACL をそのように設定します。マスターキーがなければ、トムはそれを見つけることができません。
3 つ目は Cloud Code です。beforeSave/afterSave 関数を使用して、ミッション クリティカルなビジネス ルールとデータ検証を適用できます。本当に重要なものを判断し、これらの関数で検証されていることを確認してください。これらの関数で ACL を明示的に設定することもお勧めします。オブジェクトの作成時に ACL を渡すことができますが、エンド ユーザーがこれらを改ざんする可能性があります。
セキュリティと整合性に関する経験則の概要を次に示します。
オブジェクトのアクセス許可は、要件をサポートするために必要なだけオープンにする必要があります。
すべてのレコードには ACL が必要です。
ほとんどの ACL は、before/afterSave 関数で設定する必要があります。
適用する必要がある検証は、before/afterSave 関数で確認する必要があります。
最後に、すべてのビジネス ロジックを「重要」と考え、「完全な整合性」を主張しがちです。これは多くのアプリにとってやり過ぎです。1 人のユーザーがあなたや他のユーザーに害を及ぼさないように、サーバー側で十分な保護が行われていることを確認してください。これ以上 (サポート コスト以外) を心配してもあまり意味がありません。誰かがあなたのアプリを試していて、意図的または無意識に他の人に干渉することを妨げられている場合、おそらく彼らはそれを使用するまったく新しい方法を見つけるでしょう:)。