[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-04。"],[],[],null,["\u003cbr /\u003e\n\nFirebase Realtime Database Security Rules determine who has read and write access to your\ndatabase, how your data is structured, and what indexes exist. These rules live\non the Firebase servers and are enforced automatically at all times. Every read\nand write request will only be completed if your rules allow it. By default,\nyour rules do not allow anyone access to your database. This is to protect your\ndatabase from abuse until you have time to customize your rules or set up\nauthentication.\n\nRealtime Database Security Rules have a JavaScript-like syntax and come in four types:\n\n| Rule Types ||\n|---------------|--------------------------------------------------------------------------------------------------------------|\n| **.read** | Describes if and when data is allowed to be read by users. |\n| **.write** | Describes if and when data is allowed to be written. |\n| **.validate** | Defines what a correctly formatted value will look like, whether it has child attributes, and the data type. |\n| **.indexOn** | Specifies a child to index to support ordering and querying. |\n\nRealtime Database security overview\n\nThe Firebase Realtime Database provides a full set of tools for managing the\nsecurity of your app. These tools make it easy to authenticate your users,\nenforce user permissions, and validate inputs.\n\nFirebase-powered apps run more client-side code than those with many other\ntechnology stacks. Therefore, the way we approach security may be a bit\ndifferent than you're used to.\n| The Firebase Realtime Database handles many other security details for you. For example, we use SSL with strong 2048 bit keys for our certificates and we follow best practices for authentication tokens.\n\nAuthentication\n\nA common first step in securing your app is\nidentifying your users. This process is called *authentication* .\nYou can use [Firebase Authentication](/docs/auth)\nto have users to sign in to your app. Firebase Authentication\nincludes drop-in support for common authentication methods like Google and\nFacebook, as well as email and password login, anonymous login, and more.\n\nUser identity is an important security concept. Different users have different\ndata, and sometimes they have different capabilities. For example, in a chat\napplication, each message is associated with the user that created it. Users\nmay also be able to delete their own messages, but not messages posted by other\nusers.\n\nAuthorization\n\nIdentifying your user is only part of security. Once you know who they are, you\nneed a way to control their access to data in your database. Realtime Database Security Rules\nallow you to control access for each user. For example, here's a set of\nsecurity rules that allows anyone to read the path `/foo/`, but no\none to write to it: \n\n```text\n{\n \"rules\": {\n \"foo\": {\n \".read\": true,\n \".write\": false\n }\n }\n}\n```\n\n`.read` and `.write` rules cascade, so this ruleset\ngrants read access to any data at path `/foo/` as well as any deeper\npaths such as `/foo/bar/baz`. Note that `.read` and\n`.write` rules shallower in the database override deeper rules, so\nread access to `/foo/bar/baz` would still be granted in this example\neven if a rule at the path `/foo/bar/baz` evaluated to false.\n\nThe Realtime Database Security Rules include\n[built-in variables](/docs/database/security/rules-conditions)\nand functions that allow you\nto refer to other paths, server-side timestamps, authentication information,\nand more. Here's an example of a rule that grants write access for\nauthenticated users to `/users/\u003cuid\u003e/`, where \\\u003cuid\\\u003e is\nthe ID of the user obtained through Firebase Authentication. \n\n```text\n{\n \"rules\": {\n \"users\": {\n \"$uid\": {\n \".write\": \"$uid === auth.uid\"\n }\n }\n }\n}\n```\n\nData validation\n\nThe Firebase Realtime Database is schemaless. This makes it easy to change things\nas you develop, but once your app is ready to distribute, it's important for\ndata to stay consistent. The rules language includes a `.validate`\nrule which allows you to apply validation logic using the same expressions used\nfor `.read` and `.write` rules. The only difference is\nthat **validation rules do not cascade**, so all relevant\nvalidation rules must evaluate to true in order for the write to be allowed.\n\nThese rule enforce that data written to `/foo/` must be a string\nless than 100 characters: \n\n```text\n{\n \"rules\": {\n \"foo\": {\n \".validate\": \"newData.isString() && newData.val().length \u003c 100\"\n }\n }\n}\n```\n\nValidation rules have access to all of the same built-in functions and\nvariables as `.read` and `.write` rules. You can use\nthese to create validation rules that are aware of data elsewhere in your\ndatabase, your user's identity, server time, and much more.\n| **Note:** The `.validate` rules are only evaluated for non-null values and do not cascade.\n\nDefining database indexes\n\nThe Firebase Realtime Database allows ordering and querying data. For small data\nsizes, the database supports ad hoc querying, so indexes are generally not\nrequired during development. Before launching your app though, it is important\nto specify indexes for any queries you have to ensure they continue to work as\nyour app grows.\n\nIndexes are specified using the `.indexOn` rule. Here is an example\nindex declaration that would index the height and length fields for a list of\ndinosaurs: \n\n```text\n{\n \"rules\": {\n \"dinosaurs\": {\n \".indexOn\": [\"height\", \"length\"]\n }\n }\n}\n```\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nNext steps\n\n- [Get started](/docs/database/security/get-started) planning rules development for your database.\n- Learn more about [securing your data](/docs/database/security/core-syntax) using security rules.\n- Learn more about [specifying indexes](/docs/database/security/indexing-data) using rules."]]