1. Planning (Requirements & Threat Modeling)
The only apps I develop and release are Zoom in-meeting apps, and I intentionally restrict both functionality and data access to reduce risks.
Minimal Data Handling: The only data accessed is the participant’s name, which is read via Zoom’s in-meeting API scopes. This is not stored, saved, or transmitted elsewhere.
Behavior-Based Logic Only: The app processes only user actions and interactions within the meeting (e.g. hand-raising), not content or personal data.
Strict Scope Use: Zoom OAuth scopes are limited to the minimum required (principle of least privilege). No access is requested for contacts, emails, chat, or recordings.
OAuth Usage: OAuth is used once for app activation and not retained. The app does not require continued login or any long-term tokens.
No Persistent Storage: Since the app uses no databases, there is no attack surface related to SQL injection, storage leaks, or credential theft.
As a result, threat exposure is very low.
2. Design (Architecture and Security Controls)
SSL Encryption: All endpoints are protected using HTTPS.
Secure Headers: I use the
helmetmiddleware in Node.js to enforce HTTP headers such as:Content-Security-PolicyX-Frame-OptionsStrict-Transport-Security
Firewalling and Access Control:
Admin tools are IP-restricted to my office IP only.
SSH and server admin access is protected by 2FA and limited ports.
Scoping Zoom API Usage: Only in-meeting APIs are used, with no unnecessary API calls or endpoints exposed.
3. Development (Secure Coding Practices)
With 40+ years of software development experience, I follow robust principles of clean, secure, modular coding.
Development Process:
Local Prototype: Developed and tested using
ngroktunnels and my Business Pro Zoom account.Live Sandbox: A generic live app is tested on a dedicated FASTHOSTS server using controlled test environments.
Project-Specific Stripdown: Functionality is stripped back for purpose-built versions of the app.
Beta Test Deployment: Installed on a dedicated Zoom demo account and verified in realistic meeting scenarios.
Peer Feedback Testing: Beta version is shared with trusted testers for feedback.
Production Release: Once verified, the app is submitted to the Zoom Marketplace.
Cloud-based Environments: I also use AWS EC2 instances for load and cross-platform testing.
4. Testing (Functional & Security Testing)
Functional Testing:
All interactive elements are tested in live Zoom environments using multiple roles (host, co-host, participant).
Real-time scenarios simulate potential misuse (e.g. rapid hand-raising) to ensure accurate response by the app.
Security Testing:
Input Validation: All inputs are controlled (e.g. dropdowns), and no free-text fields or file uploads are used.
No Database Risk: Since no backend storage exists, risk of injection or persistence-based attacks is eliminated.
Injection Resistance: Any potential abuse (like blocking all “Johns”) would require malicious JS injection — not possible in the production environment.
Tools used:
Manual pen testing
Browser-based inspection tools (ZAP, Chrome DevTools)
OAuth flow validation
5. Release (Secure Deployment)
Hosting Environment: Dedicated Node.js and WordPress server, firewalled with restricted port access.
Admin Access:
Restricted by static IP
Enforced 2FA
All management over secure channels
Open Ports: Only essential ports are allowed (DNS, HTTP/S, Email).
Planned Enhancements: Cloudflare will be introduced on production apps to add DDoS protection and global CDN caching.
Code Hygiene: No unused endpoints or test routes are left in production builds.
6. Maintenance & Monitoring
Uptime Monitoring: UptimeRobot is used to monitor service availability.
Local Logging: Basic server logs are maintained for monitoring app behavior and tracing issues.
Update Schedule: Libraries are reviewed monthly and updated as needed.
Security Review: Manual security checks are conducted at every version release.
7. Summary
By keeping the scope narrow, the data minimal, and the architecture clean, this SSDLC is well-suited to a solo developer environment. I focus on least privilege, modular testing, and zero storage risks, which combine to create a secure, stable foundation for every Zoom app released.
