Is this Apps Script Web App architecture safe for infrastructure monitoring?

Google Workspace Developers Q&A
,
1

Hello everyone.

I am building a small infrastructure monitoring and management dashboard using Google Workspace tools.

The current architecture is:

Google Sheets → Apps Script V3 API → Web App Dashboard → GIS Map / KPI / Risk / Reports

The system works in a near-real-time / refresh-based real-time model. Operational data is collected into Google Sheets, processed by Apps Script, and then displayed in a web dashboard. The dashboard includes GIS map points, KPI cards, risk indicators, network analytics, and daily reports.

The Google Sheet itself is restricted and not publicly shared. The Apps Script Web App reads data from the Sheet and serves the dashboard.

I would like to ask for advice on security and best practices:

  1. Is this architecture generally acceptable for a small operational monitoring system?
  2. If the Web App is deployed with “Execute as me”, what are the main security risks?
  3. Is it acceptable to make the Web App accessible by link if it only exposes read-only, sanitized dashboard data?
  4. What is the best way to separate public dashboard data from internal/private operational data?
  5. Should I create a separate read-only/public Sheet or cache layer for the dashboard instead of reading directly from the master Sheet?
  6. What are the recommended practices for Apps Script Web App API endpoints?
  7. How should I protect tokens, API keys, spreadsheet IDs, and configuration values?
  8. Are there any specific risks when using Google Sheets as the main data layer for a near-real-time dashboard?

My main goal is to keep the master data protected while allowing a dashboard to display only safe aggregated information such as total map points, risk categories, KPI values, and non-sensitive GIS data.

I am not asking for code review or penetration testing. I am mainly looking for architecture-level security guidance and best practices for Apps Script Web Apps.

Any security recommendations or architecture improvements would be greatly appreciated.

Thank you.

2

Yes, this architecture is generally fine for small monitoring dashboards, especially if the exposed data is read-only and sanitized. The biggest recommendation is to avoid serving data directly from the master Sheet. A separate cached/read-only layer is usually safer and scales better.

I’ve used a similar approach for interactive calculation tools where users change inputs and the dashboard updates dynamically in real time. One thing that helped a lot was separating the public calculation layer from the protected source data and limiting exposed endpoints to aggregated values only.

For example, this type of live modeling approach works well in tools like:

(URL Removed by Staff)

Also:

  • Store secrets in Properties Service, not hardcoded

  • Restrict Apps Script scopes as much as possible

  • Add caching to reduce Sheet reads

  • Never expose spreadsheet IDs or raw operational data to the frontend

For small internal systems, Apps Script + Sheets can work surprisingly well if you keep the architecture simple and isolated.