Private fields
Description
According to the rules provided in the configuration file, objects and object fields can be accessed by unauthorized users.
Remediation
When accessing the application through GraphQL, it is important to validate whether or not the user is given access to the requested elements from the schema. Access control policies must therefore be implemented on every path of the Graph leading to the given field or object.
The authorization logic belongs to the business logic layer, and from there it is accessed by GraphQL. This way, the application can have a single source of truth for authorization, which can then be used for other access points.
Among the several access control policies that can be implemented in an application, the two most popular ones are Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). - With Role-Based Access Control, permissions are granted based on roles which are later assigned to the users. For instance, WordPress has an administrator role with access to all resources, and the editor, author, contributor, and subscriber roles which each restrict permissions in various degrees, such as being able to create and publish a blog post, just create it, or simply read it. - With Attribute-Based Access Control, permissions are granted based on metadata that can be assigned to different entities including users, assets, or environment conditions (the time of the day or the visitor's IP address for example). In the WordPress example, the capability edit_others_posts is used to validate whether or not the user can edit other users' posts.
For most use cases, ABAC is preferable to RBAC as it allows for finely tuned permissions with explicit goals.
GraphQL Specific
Apollo
Ensure that private fields in the Apollo framework engine are properly encapsulated and not directly accessible from outside the class. Use appropriate access modifiers like 'private' to declare fields that should not be exposed, and provide controlled access through public methods if necessary. Regularly review your codebase to adhere to the principle of least privilege, only exposing what is necessary for the operation of the application.
Yoga
Ensure that all private fields in the Yoga framework engine are properly encapsulated and can only be accessed through getter and setter methods. This will help maintain the integrity of the data and prevent unauthorized access or modification of the internal state. Additionally, consider using TypeScript or similar tools that provide better support for private fields and enhance type safety in your codebase.
Awsappsync
Ensure that all sensitive data, such as API keys and user credentials, are stored in AWS Secrets Manager or another secure storage service. Do not hardcode sensitive information within the AWS AppSync resolvers or schema definitions. Implement fine-grained access control using AWS Identity and Access Management (IAM) to restrict who can access the AppSync API and what actions they can perform. Regularly audit and rotate credentials to minimize the risk of unauthorized access.
Graphqlgo
Ensure that private fields in your GraphQL schema are properly encapsulated and are not exposed through the API. Implement field-level permissions and use schema directives to control access to sensitive data. Regularly review your schema and resolver functions to verify that private fields are only accessible to authorized users.
Graphqlruby
In the GraphQL Ruby framework, ensure that private fields are not inadvertently exposed through the API. Use the private keyword to define private fields within your Ruby classes, and apply proper scoping rules to control access. Additionally, leverage the built-in visibility feature of GraphQL Ruby to control field visibility at the schema level. This can be done by defining visibility methods or using the visible? method on field definitions to determine if a field should be accessible to the current querying user. Always include tests to verify that private fields are not exposed to unauthorized users.
Hasura
Ensure that all sensitive fields are marked as private in the Hasura schema and access permissions are properly configured to prevent unauthorized access to private fields.
REST Specific
Asp_net
Ensure that all sensitive fields within objects are marked as private and utilize proper encapsulation. Implement strong access control checks within the ASP.NET framework to prevent unauthorized access to object fields. Regularly review your codebase for adherence to the principle of least privilege and update your access control mechanisms accordingly.
Ruby_on_rails
In Ruby on Rails, ensure that private fields are not exposed to unauthorized users by using strong parameters. Implement attr_accessor for fields that should be modifiable and use private or protected keywords for sensitive fields. Leverage the before_action callback to check user permissions before granting access to certain controller actions. Additionally, employ the current_user method to verify user identity and scope queries to the current user's accessible data using Active Record associations and scopes.
Next_js
Ensure that all sensitive fields within your Next.js application are declared as private class fields or encapsulated within modules, and utilize proper access control checks before exposing any user data. Implement server-side authentication and authorization mechanisms to restrict access to private fields based on user roles and permissions. Regularly audit your codebase to adhere to the principle of least privilege, and keep your access control logic up-to-date with the latest security practices.
Laravel
In Laravel, ensure that you are using Eloquent's built-in methods for data access and manipulation, which automatically protect against unauthorized access. Implement proper authentication and authorization checks using middleware, policies, and gates to control access to private fields and objects. Additionally, use Laravel's Mass Assignment protection by defining $fillable or $guarded properties on your models to prevent unauthorized updates to sensitive fields.
Express_js
Ensure that all private fields in Express.js applications are properly encapsulated and not directly accessible from the client side. Implement middleware for authentication and authorization checks to restrict access to sensitive object fields based on user roles and permissions. Use closures or Symbols in JavaScript for true privacy, and consider leveraging Object.defineProperty() to create private fields with getters and setters. Regularly review your codebase for accidental global variable leaks and enforce strict access control policies in your application logic.
Django
Ensure that Django models use the appropriate field-level permissions and queryset filtering to prevent unauthorized access to private fields. Implement Django's built-in authentication and permission classes, and override get_queryset in your views to filter data based on the current user's permissions.
Symfony
In the Symfony framework, ensure that access to private object fields is controlled by using the built-in security features. Define access control rules in 'security.yaml', use Voters for fine-grained permissions, and leverage the 'security.authorization_checker' service to explicitly check access rights in your code. Additionally, avoid exposing sensitive fields through serialization groups when using the Serializer component.
Spring_boot
Ensure that the Spring Boot application uses proper access modifiers for fields and methods. Leverage the @JsonIgnore annotation to prevent sensitive fields from being serialized and exposed in responses. Implement method-level security with @PreAuthorize or @Secured annotations to restrict access to API endpoints based on user roles or permissions. Additionally, use Spring Security's ACL module for fine-grained access control over domain objects.
Flask
Ensure that Flask routes that handle sensitive data are protected with appropriate authentication and authorization checks. Use Flask extensions like Flask-Login or Flask-Security for user session management, and decorators such as @login_required to restrict access to private fields. Additionally, validate and sanitize all user inputs to prevent injection attacks.
Nuxt
Ensure that all private fields in Nuxt.js components are properly encapsulated and not exposed to the client side. Use the Vue.js data function for component-specific state and computed properties for derived state. Avoid using or modifying the window object directly, and utilize Nuxt.js modules or plugins to manage global state and side-effects.
Fastapi
Ensure that all endpoint handlers in FastAPI validate user permissions before accessing or modifying private fields. Implement role-based access control (RBAC) and use dependency injection to verify the user's role at the start of each request. Additionally, consider using Pydantic models to explicitly define which fields are accessible for reading or writing based on the user's role.
Configuration
Identifier:
access_control/private_fields
Options
- empty_values_are_positive : When the API returns a None value without error is the field considered to be successfully accessed ?
Parameters
__user : (For Graphql) An object {objectName:[fieldName]} represting object fields that the user is not supposed to have access to.
rules : (For REST) The list of private fields rules to check during a scan.
Examples
GraphQL: Accessiblity of private objects in a GraphQL API for not authenticated users.
{
"auth": {
"public": { #
"tech": "public" # Default value on a new application
}, #
... REDACTED AUTH ...
},
"users": {
"public": { #
"auth": "public" # Default value on a new application
}, #
"exampleUser": {
... REDACTED AUTH ...
}
}
... Other configuration settings ...
"checks": {
... Other checks ...
"access_control/private_fields": {
"public": { <--- Triggering on a "users" object key
"Query": [ <--- Object name
"getUsersById", <--- Field name
"getAllUsers" # Here, the public user is not supposed to
# have access to the "getUsersById" and "getAllUsers" queries.
],
"Mutation": [
...
],
"User": [ docs
"id" # Here, the public user is not supposed to
# have access to the "id" field of the "User" object
]
}
}
... Other checks ...
}
... Other configuration settings ...
}
REST: Ensure user some-user cannot access the routes GET /admin and PUT /user/role/{roleId}
{
"auth": { #
... REDACTED AUTH ...
},
"users": {
... Other users ...
"some-user": { # User to check
... REDACTED AUTH ...
}
... Other users ...
}
... Other configuration settings ...
"checks": {
... Other checks ...
"AccessControl_PrivateFields": {
"parameters": {
"rules": [
"user": "some-user",
"routes": [
{
"method": "GET",
"path": "/admin"
},
{
"method": "GET",
"path": "/admin/.*" # Regex are supported
},
{
"method": "PUT",
"path": "/user/role/{roleId}"
}
]
]
}
}
... Other checks ...
}
... Other configuration settings ...
}
REST: Ensure user some-user cannot access the fields email and credentials.apiKey route GET /admin
{
"auth": { #
... REDACTED AUTH ...
},
"users": {
... Other users ...
"some-user": { # User to check
... REDACTED AUTH ...
}
... Other users ...
}
... Other configuration settings ...
"checks": {
... Other checks ...
"AccessControl_PrivateFields": {
"parameters": {
"rules": [
"user": "some-user",
"routes": [
{
"method": "GET",
"path": "/admin",
"fields": [
"email",
"credentials.apiKey"
]
}
]
]
}
}
... Other checks ...
}
... Other configuration settings ...
}
REST: Ensure user some-user cannot access a field admin-* on route GET /admin
{
"auth": { #
... REDACTED AUTH ...
},
"users": {
... Other users ...
"some-user": { # User to check
... REDACTED AUTH ...
}
... Other users ...
}
... Other configuration settings ...
"checks": {
... Other checks ...
"AccessControl_PrivateFields": {
"parameters": {
"rules": [
"user": "some-user",
"routes": [
{
"method": "GET",
"path": "/admin",
"fields": [
"admin-*",
]
}
]
]
}
}
... Other checks ...
}
... Other configuration settings ...
}
Ignore this check
checks:
access_control/private_fields:
skip: true
Score
- Escape Severity: HIGH
Compliance
OWASP: API1:2023
pci: 7.1
gdpr: Article-32
soc2: CC1
psd2: Article-95
iso27001: A.18.1
nist: SP800-53
fedramp: AC-6
Classification
- CWE: 284
Score
- CVSS_VECTOR: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N/E:H/RL:O/RC:C
- CVSS_SCORE: 5.1