🎉 acap-v2 - v10.1.0-alpha.10, dev branch @95a97cd is released. Read more →
Security

Security Guidelines

ACAP adheres to strict security practices and development patterns defined by its technology stack "while considering compatible options with its limited (default) upgradable standard-pricing cloud services" starting from its initial 1.0 version.

Please ensure continued compliance with these security standards when extending ACAP to add or enhance new features while actively considering its currently available plans, options, and feature requirements at hand.

☠️

NOTE: Further enhancements and feature updates to the initial ACAP 1.0 version may introduce new requirements to address additional use cases. Please ensure that security measures meet the expectations outlined in these new requirements.

Database

  1. Manually test and ensure using the Firestore Web API (opens in a new tab) and Firestore REST APIs (opens in a new tab) that:

    • (a) Signed-in users cannot perform CREATE/EDIT/DELETE operations in the Firestore collections and documents defined in the Firestore Rules.

      ⚠️

      NOTE: If there is a need to perform CREATE/EDIT/DELETE operations "directly" in the Firestore collections or documents using the Firestore Web API (opens in a new tab) or Firestore REST APIs (opens in a new tab), please ensure the creation and testing of robust, new Firestore Rules (opens in a new tab) that will meet the "new" requirements (ACAP 1.0 only performs such operations thru the backend NodeJS REST APIs, Database #2, Database #3). This ensures manageable security and safety, preventing security breaches like the cross-site scripting (XSS) attack example detailed at:

      XSS Vulnerability Awareness in ACAP 2.0

    • (b) Signed-in users cannot CREATE new Firestore collections and documents

    • (c) Public users without sign-in authentication cannot VIEW sensitive information such as phonebook contacts and email information, by ensuring their Firestore collections are using the correct role/access-based Firestore Security Rules.

  2. Ensure that all mutative "WRITE" operations in the Firestore database occur only through authenticated HTTPS requests in the backend (NodeJS) REST APIs. (see also Server for more information).

    • (a) ACAP 1.0's Firestore Rules strictly prohibits Database #1.a and Database #1.b to enforce this.
    • (b) If new requirements allow item Database #1.a to "directly" perform CREATE/EDIT/DELETE operations in Firestore collections or documents using the Firestore Web API (opens in a new tab) or Firestore REST APIs (opens in a new tab), please ensure that "new" and robust Firestore Rules (opens in a new tab) are created and thoroughly tested. These Rules may need to be separate from ACAP 1.0, which "discourages this approach unless Firestore Rules can be properly enforced".

  3. Ensure proper server-side validation when mutating data through the backend (NodeJS) REST APIs using validation scripts in middleware or the controller scripts.

  4. Firestore database security relies on properly tested Firestore Rules to ensure security, especially if its rules do not disable all VIEW/CREATE/EDIT/DELETE operations.

    • Please ensure that "new" and robust Firestore Rules are created and thoroughly tested, in case new database components or requirements need to be added to the ACAP 1.0 Firestore database.

Firestore Database Rules

ACAP's Firestore Security Rules (opens in a new tab), which enforces strict role/access-based security to the Firestore database, should be copied to the Firebase project's Firestore Rules tab in the Firebase Console (opens in a new tab). It is located in this file for reference:

/client/src/firestore.rules
⚠️

ACAP 2.0 allowed users to edit crop recommendations, a new feature introduced in version 2.0 through weak Firestore Security Rules, making it vulnerable to Cross-Site Scripting (XSS). This lets unauthorized clients (e.g., Postman) modify WYSIWYG-form data without protection if accessed from the Firestore REST APIs (opens in a new tab). Allowing these in the Firestore Security Rules contradicts the best practices outlined in the Database section, which advocates for data mutation with thorough data validation/sanitation in the Node backend.

For more details, refer to GitHub Issues in the parent acap-v2 repository ([1] (opens in a new tab), [2] (opens in a new tab)) or check the Firebase Storage Announcements 2024 under the Are there security concerns I should be aware of? section for information and reference.

Sensitive data management

  1. Ensure sensitive data and environment variables are never statically generated and deployed to the GitHub Pages or Firebase Hosting static hosting websites.

  2. Sensitive data, secured with Firebase Authentication, Firebase Custom Claims (User/Admin Accounts #1, #2), and Firestore Rules (Database #1.c), is dynamically fetched from the Firestore Database using the Firestore Web APIs or the secure (NodeJS) REST APIs.

    💡

    Ensure that Firestore collections containing sensitive data (e.g., "/phonebook/{docId}") are using appropriate role/access-based access settings defined in the Firestore Security Rules. This comprises a combination of Firebase Authentication and Firebase Custom Claims.

File Storage

Manually test and ensure, using the Firebase Storage Web APIs, that:

  1. Public and signed-in users can only "READ" or download the PDF bulletin files.
  2. Public and signed-in users cannot UPLOAD or DELETE files.

Firebase Storage Security Rules

ACAP's Firebase Storage Security Rules (opens in a new tab) enforce strict security by allowing only authenticated requests in the NodeJS backend to upload (PDF) files to the Firebase Cloud Storage while allowing public data (PDF, images) to download from the frontend. It should be copied to the Firebase project's Storage Rules tab in the Firebase Console (opens in a new tab). It is located in this file for reference:

/client/src/storage.rules

Codebase

  • Ensure that forked climate-services-webportal-v1 (ACAP 1.0) or acap-v2 (ACAP 2.0) monorepo code base or copies remain PRIVATE in GitHub and other public platforms.

User/Admin Accounts

  1. Ensure that Admin accounts are created by the superadmin in the NodeJS backend using Firebase Authentication (opens in a new tab) with Firebase Custom Claims (opens in a new tab), leveraging the Firebase Admin SDK (opens in a new tab) to ensure maximum security.

  2. More information about ACAP's Security requirements is available in its Software Requirements Specifications document in this link (opens in a new tab) (accessible only for developers with access).

    These Security requirements carry over and apply to ACAP 2.0, even if the Software documents were written for ACAP 1.0. Since no new Software documents are available for the updates made in ACAP 2.0, you may consult the new lead programmer responsible for implementing ACAP 2.0 about detailed upgrades specifics made to the system.

Node Package Libraries (NPM)

ACAP, a web application built with Firebase, Express, React/Next.js, and Node.js, relies on open-source development libraries from the Node Package Manager (NPM) for its client and server applications.

Since ACAP's initial development in 2022, many of these libraries may have become outdated as newer versions are released.

Developers maintaining ACAP are encouraged to monitor and update these dependencies as needed to benefit from performance improvements, security patches, and new features, possibly requiring using newer Node versions.

Related

References

Firebase Authentication

  1. Firebase Authentication [link] (opens in a new tab)
  2. Firebase Custom Claims [link] (opens in a new tab)
  3. Firebase Admin SDK [link] (opens in a new tab)

Database

  1. Firestore Web API [link] (opens in a new tab)
  2. Firestore REST APIs [link] (opens in a new tab)
  3. Firestore Rules [link] (opens in a new tab)

Online Storage

  1. Firebase Storage Web APIs [link] (opens in a new tab)
ChecklistFolder Structure