Meetin.gs Security
Review Meetin.gs security principles for calendar privacy, access, transport, sessions, integrations, operations, and reporting.
Calendar privacy by design
Availability requires a free/busy decision, not disclosure of private event titles or descriptions. Connected-calendar implementations should request the minimum scope, separate blocking state from calendar content, and provide a clear disconnect path.
- Guests never need an account. A name is enough to vote; an email is optional for confirmations.
- Organizer access is Google-verified. See the free account page for what is stored.
- Private titles never reach a public page. The security overview lists the controls.
- Email delivery is logged and inspectable per booking; the privacy policy covers retention.
Application and operational controls
Production deployments should use encrypted transport, strong secret storage, protected session cookies, least-privilege database access, dependency updates, rate controls, backups, logging, and recovery tests. Administrator and integration actions need attributable audit records.
Secure scheduling lifecycle
Public scheduling links must not reveal private management tokens. Booking, reschedule, cancellation, poll finalization, calendar delivery, and email callbacks should validate identifiers and remain safe under retries and concurrent submissions.
Report a security concern
Use the contact form with the affected URL, impact, and safe reproduction steps. Do not access data that is not yours, disrupt the service, or include secrets in the initial report.
Security verification checklist
| Area | Objective | Test |
|---|---|---|
| Public pages | Reveal only intended invitee information. | Inspect signed out and try invalid identifiers. |
| Private actions | Require private tokens and CSRF protection. | Attempt the action without authorization. |
| Input | Constrain size, format, and state. | Use malformed, duplicate, and boundary values. |
| Connections | Use least privilege and safe retries. | Revoke access and duplicate callbacks. |
| Operations | Detect and recover accountably. | Exercise backup, restart, and escalation. |
Security questions
Does the public scheduler expose calendar details?
It should use availability decisions, not private titles or descriptions. Connected-calendar work remains requirements-only until permissions and privacy boundaries are deployed and tested.
How are private routes kept out of search?
Event, booking, management, calendar-file, dashboard, and utility routes use noindex controls and are excluded from the canonical sitemap.
How to use Meetin.gs Security as an operating reference
Review Meetin.gs security principles for calendar privacy, access, transport, sessions, integrations, operations, and reporting. Begin with limit access: Use the smallest permission and data scope that can do the job. Then apply protect tokens: Keep private management links and secrets out of public pages. Finish with test recovery: Exercise retries, backups, cancellation, and failure handling.
Meetin.gs Security in brief
Limit access
Use the smallest permission and data scope that can do the job.
Protect tokens
Keep private management links and secrets out of public pages.
Test recovery
Exercise retries, backups, cancellation, and failure handling.
Public product and editorial pages use stable slugs and distinguish the testable booking-and-polling core from advanced roadmap capabilities. That distinction is part of the site's product and content standard.
For any request, include only the context needed for the stated purpose. Clear identifiers, expected behavior, and lifecycle state are more useful than copied calendar content or sensitive free text. This keeps support, editorial references, legal questions, and security reports focused and safer to handle.
