Compliance & Security
Master security and compliance for Buzzy applications. Learn server-level protection, Organizations/Teams, Viewers fields, and legal requirements.
Security Is Built Into Buzzy
Non-technical explanation: When you build an app, you're like a store owner responsible for protecting customer information. Buzzy gives you a professional security system (like cameras, locks, and alarms), but you need to configure it correctly—deciding who gets keys to which rooms and what they can access.
When building applications, you accept responsibility for user data and security. Buzzy's no-code platform provides server-level security features that protect your users—but you must configure them correctly.
Why security matters:
This guide covers:
✅ Buzzy's server-level security model (not just UI hiding)
✅ Organizations and Teams for access control
✅ Viewers and Team Viewers fields for data protection
✅ Data protection best practices
✅ Legal compliance requirements (GDPR, privacy)
✅ Complete security configuration checklist
Understanding Buzzy's Security Model
Security vs. Obscurity
Critical concept: Hiding UI elements is NOT security.
❌ Wrong approach (security by obscurity):
Use display rules to hide sensitive data
Assume users won't find hidden API endpoints
Trust client-side validation only
✅ Right approach (server-level security):
Use Viewers fields to control data access at the server
Configure Organizations and Teams properly
Validate data at the server level (Buzzy handles this)
Example scenario: You build an HR app where employees can view their own salary but not others' salaries.
❌ Bad: Display rule that hides salary field if record.employeeId ≠ $currentUser._id
Problem: User can still access the data via API or by inspecting network requests
✅ Good: Viewers field on Salary Datatable set to the employee
Buzzy's server enforces this—user literally cannot access other employees' salary data
Learn more about Buzzy's security model
Buzzy's Built-In Security Features
1. Authentication (Handled by Buzzy)
Buzzy provides authentication automatically:
What Buzzy handles:
User registration and login
Password hashing and storage
Session management
Password reset flows
OAuth integration options
What you configure:
Authentication method (email/password, OAuth providers)
Password requirements (if using email/password)
User profile fields
You don't write authentication code - Buzzy's Core Engine handles this securely.
2. Server-Level Authorization with Viewers Fields
Viewers fields are Buzzy's primary security mechanism for controlling who can access data.
How it works:
Add a "Viewers" field to any Datatable
Set the field value to user IDs who should have access
Buzzy's server enforces access—users not in Viewers cannot see the data
Example: Personal Documents
When user creates a document, set:
viewers: [$currentUser._id]Result: Only the creator can access this document. Even if another user has the direct URL or API endpoint, Buzzy's server will deny access.
Example: Shared Documents
Document shared with multiple users:
viewers: [creator._id, collaborator1._id, collaborator2._id]Result: Only these three users can access the document.
Learn more about Viewers fields
3. Team-Based Security with Team Viewers
Team Viewers fields extend security to team-based access control.
How it works:
Create Buzzy Teams within Organizations
Add "Team Viewers" field to Datatables
Set field to Team IDs that should have access
All team members automatically get access
Example: Project Management App
Project belongs to "Engineering Team":
teamViewers: [engineeringTeam._id]Result: All members of Engineering Team can access the project. When team membership changes, access automatically updates.
Benefits:
No manual user list management
Access updates automatically when team membership changes
Scales to large organizations
Integrates with Buzzy's Organization structure
4. Organizations for Multi-Tenant Apps
Organizations enable true multi-tenant SaaS applications in Buzzy.
How it works:
Each customer gets their own Organization
Users belong to Organizations
Data is scoped to Organizations
No data leakage between Organizations
Example: SaaS Application
You build a project management tool with multiple client companies:
Company A users only see Company A projects
Company B users only see Company B projects
Admins can manage their own organization
Implementation:
Use Buzzy's built-in Organization object
Link Datatables to Organizations
Filter data by
$currentUser.organization
Learn more about Organizations pattern
Common Security Mistakes in Buzzy Apps
Mistake 1: Using Display Rules for Security
❌ Wrong:
Display rule: Show "Delete" button only if:
$currentUser.highestRole = "admin"Problem: User can still call the delete action via API inspection or direct URL.
✅ Right:
Add Viewers field to the Datatable
Only admins in Viewers can delete
Use display rule for UX only (not security)
Remember: Display rules are for user experience, Viewers fields are for security.
Mistake 2: Not Setting Viewers on Sensitive Data
❌ Wrong: Create a Datatable for "Employee Salaries" without Viewers field.
Problem: All authenticated users can potentially access all salary data.
✅ Right:
Add Viewers field to "Employee Salaries" Datatable
Set to
[employee._id, hr._id]when creating recordsOnly the employee and HR can access their salary data
Mistake 3: Exposing API Keys in Buzzy Functions
❌ Wrong:
export const main = async (event) => {
const apiKey = "sk-abc123hardcoded"; // EXPOSED!
// ...
};Problem: API key is visible in your Function code and could leak.
✅ Right:
export const main = async (event) => {
const apiKey = process.env.API_KEY; // From Buzzy Constants
if (!apiKey) {
return { statusCode: 500, body: { error: "API key not configured" } };
}
// ...
};Use Buzzy Constants (encrypted storage) for all sensitive configuration.
Mistake 4: Trusting Client-Side Validation Only
❌ Wrong: Rely on required fields and field validation in Buzzy UI only.
Problem: Users can bypass client validation by calling APIs directly.
✅ Right:
Use Buzzy's required fields (enforced server-side automatically)
Use Formula fields for validation (executed server-side)
Buzzy validates at server level—you're already protected!
Mistake 5: Not Understanding Organization Boundaries
❌ Wrong: Build a multi-tenant app without using Organizations.
Problem: Data from different customers mixed together, hard to segregate.
✅ Right:
Use Buzzy's Organization object
Each customer gets their own Organization
Filter all data by Organization
Buzzy enforces Organization boundaries
Buzzy's Platform Security Features
What Buzzy Handles Automatically
Authentication & Sessions:
✅ Password hashing (you never see plain text passwords)
✅ Session management (secure, httpOnly cookies)
✅ HTTPS encryption (automatically enabled)
✅ CSRF protection (built into platform)
✅ XSS prevention (Buzzy's rendering engine handles this)
Data Security:
✅ SQL injection prevention (Buzzy uses MongoDB, no SQL)
✅ Server-side validation (required fields enforced)
✅ Encrypted data transmission (HTTPS everywhere)
✅ Secure API endpoints (authentication required)
What this means for you: You don't write authentication code, session management, or worry about XSS/SQL injection. Buzzy's Core Engine handles these security fundamentals. Your job is to configure security correctly using Viewers fields, Teams, and Organizations.
Security Testing for Buzzy Apps
What to Test
Access control testing:
Create test user accounts with different roles
Try to access data that should be restricted:
Can User A see User B's personal data?
Can regular users see admin-only data?
Can users from Organization A see Organization B's data?
Test with direct URLs and API calls (not just UI)
Example test scenarios:
Personal Data Pattern:
User A creates a document with
viewers: [userA._id]Log in as User B
Try to access User A's document URL directly
Expected: Access denied (Buzzy should block this)
Team Pattern:
Add User A to "Sales Team"
Create project with
teamViewers: [salesTeam._id]Log in as User B (not in Sales Team)
Try to access the project
Expected: Access denied
Organization Pattern:
Create two test Organizations
Add data to Organization A
Log in as user from Organization B
Try to access Organization A's data
Expected: Should see no data or access denied
Testing Buzzy Functions
Security testing for Functions:
Tools and Approaches
Manual testing:
Create multiple test user accounts
Use incognito/private browsing for different users
Test on different devices (web, iOS, Android)
Check browser network tab for data exposure
Buzzy platform monitoring:
Review Buzzy Function logs for errors
Monitor app usage patterns
Check for unusual access attempts
Review user feedback for security concerns
Privacy & Compliance for Buzzy Apps
Understanding Your Compliance Needs
Key factors:
Geographic location of your users
Type of data you collect
Industry regulations (healthcare, finance, etc.)
Age of users (children's privacy)
Important: Buzzy provides the platform infrastructure and security features, but you are responsible for using them correctly to meet your compliance requirements. Consult with legal counsel for your specific compliance needs.
GDPR (European Union)
Applies if: You have users in the EU
Key requirements:
Consent: Clear opt-in for data collection
Access: Users can request their data
Deletion: Users can request data deletion ("right to be forgotten")
Portability: Users can export their data
Privacy by design: Security built-in from the start
Breach notification: Report breaches within 72 hours
Implementation in Buzzy:
Data access: Use Buzzy REST API with user authentication to export user data
When a user authenticates with their credentials (X-Auth-Token and X-User-Id), Buzzy's server automatically filters data based on Viewers fields
Calling
POST /api/microappdatawith the user's auth token returns only data they have access toSee Buzzy REST API documentation for details
For GDPR-compliant data export, you can create a Buzzy Function that calls the REST API with the user's authentication to gather all their accessible data
Account deletion:
Build a "Delete My Account" feature in your app
Use Buzzy REST API to delete user's data across all Datatables
Remove user from all Viewers and Team Viewers fields
Delete user account via Buzzy's user management
See Buzzy REST API documentation for data deletion endpoints
Data portability:
Create a Buzzy Function that exports user data in standard format (JSON, CSV)
Use authenticated REST API calls to fetch data the user has access to
Users can download their complete data package
Include all Datatables where user has Viewers access
CCPA (California)
Applies if: You have California residents as users
Key requirements:
Disclosure: Tell users what data you collect
Knowledge: Users can request details about their data
Deletion: Users can request data deletion
Opt-out: If you sell data (most don't), users can opt out
Non-discrimination: Can't penalize users for exercising rights
Implementation in Buzzy:
Similar to GDPR implementation
Provide clear privacy policy
Build data export feature
Build account deletion feature
HIPAA (Healthcare - United States)
Applies if: You handle protected health information (PHI)
Key requirements:
Security Rule: Physical, administrative, technical safeguards
Privacy Rule: Control who accesses PHI
Breach Notification: Report breaches to affected individuals
Business Associate Agreements: Required for vendors
Buzzy considerations:
Use Viewers fields to strictly limit PHI access
Ensure only authorized healthcare providers can see patient data
Use Organizations for different healthcare facilities
Consider HIPAA-compliant hosting if needed
Consult HIPAA compliance experts
Healthcare apps require expert legal review. HIPAA compliance is complex and violations have serious penalties. If you're building a healthcare app, work with legal and compliance professionals.
COPPA (Children's Privacy - United States)
Applies if: Your app targets children under 13
Key requirements:
Parental consent for data collection
Limited data collection (only necessary data)
No behavioral advertising to children
Enhanced security measures
Most apps: Add age verification, require users to be 13+
Implementation in Buzzy:
Add age field in user registration
Block registration if under 13 (or require parental consent)
Store minimal data for users under 13 if you allow them
Privacy Policy Requirements
Every Buzzy app must have a privacy policy if it collects user data.
Must include:
What data you collect:
User account information (email, name, profile data)
Application data (what they create/store in your app)
Usage data (if you're tracking analytics)
Technical data (Buzzy collects some automatically)
Why you collect it:
Provide the service
Improve the product
Communicate with users
Comply with legal obligations
How you use it:
Store in Buzzy's secure infrastructure
Process for app functionality
Analyze for improvements (if applicable)
Who you share it with:
Buzzy (the platform provider)
Any third-party integrations (via Buzzy Functions)
Whether you sell data (most don't)
How long you keep it:
While account is active
Retention period after account deletion
Legal retention requirements
User rights:
Access their data
Export their data
Delete their account
Correct inaccurate data
Security measures:
Buzzy's platform security features
Your additional security measures
How you handle breaches
Contact information:
How users can reach you about privacy
Data protection officer (if required)
Example privacy policy structure:
# Privacy Policy for [Your App Name]
## Data We Collect
We collect the following information:
- Account information: email, name, [other profile fields]
- Application data: [what your app stores]
- Usage information: [if tracking analytics]
## How We Use Your Data
Your data is used to:
- Provide and maintain the service
- Improve the application
- Communicate with you about the service
## Data Storage and Security
Your data is stored securely using Buzzy's cloud infrastructure, which includes:
- Encrypted data transmission (HTTPS)
- Access control and authentication
- Regular security updates
[Add any additional security measures you implement]
## Third-Party Services
We use the following third-party services:
- Buzzy (application platform)
- [List any services you integrate via Buzzy Functions]
## Your Rights
You have the right to:
- Access your personal data
- Export your data
- Delete your account and data
- Correct inaccurate information
To exercise these rights, contact us at [email]
## Contact Us
For privacy-related questions: [email]Security Checklist for Buzzy Apps
Before deploying to production, verify:
Data Security Configuration
Viewers fields:
Team Viewers (if using teams):
Organizations (if multi-tenant app):
Buzzy Functions Security
If you're using Buzzy Functions:
User Experience Security
Display rules:
Actions and forms:
Privacy & Compliance
Legal requirements:
Data collection:
Deployment Security
Production configuration:
Monitoring and Response
Ongoing security:
Security Incident Response for Buzzy Apps
If You Discover a Security Issue
1. Assess the severity:
Is user data exposed?
How many users are affected?
Is the issue still ongoing?
2. Immediate containment:
If it's a Buzzy Functions issue: disable the Function temporarily
If it's a Viewers field misconfiguration: fix immediately
If it's an external service: revoke API keys in Buzzy Constants
Document what you found
3. Fix the root cause:
Correct Viewers field configuration
Update Buzzy Functions
Rotate compromised API keys in Constants
Test the fix thoroughly
4. Assess impact and notify:
Determine what data was accessed
Notify affected users if their data was exposed
File breach reports if legally required (e.g., GDPR: within 72 hours)
5. Prevent recurrence:
Document what happened
Update your security checklist
Review similar areas of your app
Share learnings with team
Getting Help
Buzzy platform issues:
Contact Buzzy support for platform security questions
Report suspected platform vulnerabilities
Your app's security:
Review Buzzy's security documentation
Consult security professionals for sensitive apps
Consider security audit for high-risk applications
Key Takeaways
Buzzy's security advantages:
✅ Authentication handled automatically
✅ Server-level security via Viewers fields (not client-side hiding)
✅ Organizations and Teams for scalable access control
✅ Platform security updates handled by Buzzy
✅ HTTPS and encryption managed by Buzzy
Your responsibilities:
Configure Viewers and Team Viewers fields correctly
Use Buzzy Constants for sensitive data in Functions
Test access control with different user accounts
Comply with relevant privacy laws
Provide clear privacy policy
Monitor and respond to security issues
Critical principle: Security is configuration, not code. Buzzy provides the security features—you must configure them correctly for your app's needs.
Next Steps
Understand app quality: App Quality & Performance
Know limitations: What Not to Build
Learn about maintenance: Maintenance with Buzzy
Deep dive on data security: Security and Access Control
Remember: Buzzy's no-code platform provides security features that traditional vibe coding tools don't. You're not managing authentication code, session tokens, or database queries. Instead, you're configuring server-level security through Viewers fields, Teams, and Organizations. This is simpler and more maintainable—but you must configure it correctly. When handling sensitive data or building regulated apps, always consult legal and security professionals.
Last updated