Apply suggestions from code review

Co-authored-by: Mauro Baluda <[email protected]>

Author: jeongsoolee09

javascript/frameworks/cap/src/bad-authn-authz/DefaultUserIsPrivileged/DefaultUserIsPrivileged.md

@@ -1,14 +1,14 @@
 # Default User is overwritten as privileged
 
-The user whose request cannot be verified as authenticated is represented as `cds.User.default` internally. If this property is set to `cds.User.Privileged`, then a service may provide assets to some user who has no rights to access them.
+Users that cannot be verified as authenticated are represented as `cds.User.default` internally. Setting this property to `cds.User.Privileged` may result in providing protected assets to unauthorized users.
 
 ## Recommendation
 
 ### Set up a development profile that uses non-production authentication
 
-It may be tempting to overwrite the `cds.User.default` as `cds.User.Privileged`, for ease of development. However, this may slip through production undeleted since the assignment to `cds.User.default` can be hard to detect because it may take various forms; e.g. the programmer may choose to store `cds.User` to a variable `v` and access `cds.User.default` by `v.default`.
+Overwriting `cds.User.default` as `cds.User.Privileged` for testing purposes is not recommended as such code may easily slip through production.
 
-A safer and more elegant solution is to set up a development profile and opt in to use a non-production strategy such as `"basic"`, `"dummy"`, or `"mocked"` during its use. This can be done in `package.json` of the CAP application at its project root:
+Instead, set up a development profile and opt in to use a non-production strategy such as `"basic"`, `"dummy"`, or `"mocked"` during its use. This can be done in the file `package.json` in the root folder of the CAP application:
 
 ``` json
 {
@@ -28,7 +28,7 @@ cds serve --profile dev
 
 ## Example
 
-Setting `cds.User.default` to `cds.User.Privileged` may happen anywhere in the application. The following is the server.js that provides the top-level definition of a CAP application, overwriting the property with the problematic class.
+Setting `cds.User.default` to `cds.User.Privileged` may happen anywhere in the application. In the following example, the `server.js` file provides the top-level definition of a CAP application and overwrites the `default` user property with the `Privileged` class.
 
 ``` javascript
 const cds = require("@sap/cds");

javascript/frameworks/cap/src/bad-authn-authz/EntityExposedWithoutAuthn/EntityExposedWithoutAuthn.md

@@ -10,16 +10,16 @@ CDL provides two annotations to declare access controls `@requires` and `@restri
 
 #### Check the original CDS entity it is derived from
 
-CDS entities may be derived from other entities by means of selection and projection. These derived definitions inherit its identical conditions for access control or can choose to override them. Therefore, in order to accurately determine what authorization an entity requires, the access control of the parent entity should be transitively inspected (that is, the inspection should go up the chain of derivation).
+CDS entities may be derived from other entities by means of selection and projection. Derived definitions inherit access control conditions and optionally override them. In order to accurately determine what authorization an entity requires, the access control of the parent entity should be transitively inspected.
 
 ### Enforce authorization with JavaScript
 
-Access control may be enforced when a handler for requests to the relevant entity or service is registered to a service. Both `cds.Service.before` and `cds.Service.on` may be used to enforce it. For example, to restrict writing to and updating an entity to certain role satisfying some requirements, the below handler registrations may be used interchangably:
+Access control may be enforced when a request handler for the relevant entity or service is registered. Both `cds.Service.before` and `cds.Service.on` may be used for enforcement. For example, to restrict writing to and updating an entity to a user satisfying certain requirements, the below handler registrations may be used:
 
 ``` javascript
 /**
- * Intercept requests to SomeEntity before access and check if the request
- * is coming from a user with SomeRole and level greater than 3.
+ * Before serving a request to access SomeEntity, check if the request is coming from a user
+ * with SomeRole and level greater than 3.
  */
 this.before(["WRITE", "UPDATE"], "SomeEntity", (req) => {
   (req.user.is("SomeRole") && req.user.attr.level > 3) || req.reject(403);
@@ -38,7 +38,7 @@ this.on(["WRITE", "UPDATE"], "SomeEntity", (req) => {
 
 ## Examples
 
-The following CDS definition and its JavaScript implementation imposes no authorization on SomeEntity. Note that the `OriginalEntity` from which `DerivedEntity` derives from does not control access to it, either.
+The following CDS definition and its JavaScript implementation imposes no authorization on SomeEntity. Note that the `OriginalEntity` from which `DerivedEntity` derives from does not control the access either.
 
 ### db/schema.cds