Security at Rennt

Rental companies trust Rennt with their bookings and their customers' details. This page describes, in plain English, the security practices we actually use today. It does not describe certifications we do not have: Rennt itself is not SOC 2 or ISO 27001 certified. Where a vendor holds a certification, we say so and name the vendor.

1. Every rental company's data is walled off

• Rennt is multi-tenant: many rental companies share one database, and each company's rows are tagged with its account.
• Row Level Security (RLS) is enabled on every table that holds tenant data. The database itself checks, on every query, that the signed-in user is a member of that rental company — so one company cannot read or change another company's records, even through a bug in the app.
• Actions that need extra rights (for example creating a booking from a public storefront) run through database functions that check permission inside the function.
• Anonymous (signed-out) access is limited to what a storefront needs to show, such as active products and availability.

2. Encryption

• In transit: every page, API call and storefront is served over HTTPS (TLS). Our site sends HTTP Strict Transport Security (HSTS) so browsers refuse plain-HTTP connections. Custom domains get their own TLS certificates.
• At rest: our database and file storage provider, Supabase, encrypts data at rest (AES-256) and encrypts its backups.
• Passwords are hashed by Supabase Auth; nobody at Rennt can see them.

3. Card payments

Rennt never sees or stores full card numbers. Card details are collected and processed by Stripe, a PCI DSS Level 1 certified service provider. Renter payments go to the rental company's own Stripe account; Rennt keeps only the payment status and the card brand and last four digits.

4. Least-privilege access

• The powerful server key that can bypass database rules exists only inside our server-side functions. It is never sent to browsers or stored in our website code.
• Credentials for tools a rental company connects (for example its own Twilio account) are kept in a separate table that browsers cannot read at all — even by the company that saved them. Only our server functions can use them.
• Inside the dashboard, owners control who is on their team, each person's role, and which modules are turned on.
• Platform-admin tools are restricted to Rennt administrators and checked in the database on every call.

5. Signing in

• Passwords must be at least 8 characters with upper- and lower-case letters, a number and a symbol.
• You can sign in with Google instead, which lets you use Google's 2-Step Verification.
• Multi-factor authentication inside Rennt is not offered yet. It is on our roadmap. Until then, we recommend Google sign-in with 2-Step Verification for account owners.

6. Application safeguards

• Rate limits on public endpoints such as storefront booking, chat and sign-up, to slow down abuse and automated attacks.
• Security headers on every page, including HSTS, content-type sniffing protection, and frame restrictions to prevent clickjacking.
• An automated check before every release that blocks deployments containing leaked secret keys, broken pages or broken scripts.
• A per-account activity log of important changes.
• AI features run with limits on cost and rate, and the storefront AI assistant can only create booking requests, which the rental company confirms.

7. Backups and availability

• Our database is backed up automatically by Supabase, and backups are encrypted.
• Our website and storefronts are served by Vercel's global network.
• You can export your bookings, customers and inventory as CSV files at any time.

8. Monitoring and audits

• We run an automated security audit of the database (checking for tables without access rules, unsafe permissions and integrity problems) and review our providers' security advisories.
• After releases we run automated live checks of the site, storefronts and key functions.
• We review logs from our server functions and email delivery when investigating problems.

9. Our vendors

We use established infrastructure providers. Their certifications belong to them, not to Rennt: Supabase (SOC 2 Type 2), Vercel (SOC 2 Type 2, ISO 27001), Stripe (PCI DSS Level 1), Twilio (SOC 2, ISO 27001), Resend (SOC 2 Type II). The full list of who handles what is on our Subprocessors page.

10. If something goes wrong

If we suspect a security incident, we act right away to investigate, contain it, and fix the cause. If we confirm a breach affecting a rental company's data, we will notify that rental company within 72 hours of confirming it, by email to the account owner. We will explain what happened, what data was involved, what we are doing about it, and what they should do — and we will help them meet their own notice duties to customers and regulators. Our commitments to rental companies are in the DPA.

11. Report a vulnerability

If you find a security problem, please email support@rennt.app with "Security" in the subject, and include steps to reproduce it. We will acknowledge your report within 3 business days and keep you updated.

• Please test only against your own account, do not access or change other people's data, do not degrade the Service (no denial-of-service or spam), and give us reasonable time to fix the issue before sharing it publicly.
• If you follow these rules in good faith, we will not pursue legal action against you for your research.
• We do not currently run a paid bug bounty, but we are glad to credit you once a fix ships.

12. What you can do

• Use a strong, unique password, or Google sign-in with 2-Step Verification.
• Remove team members as soon as they leave.
• Only collect the customer information you need. Do not put card numbers or ID numbers in booking notes.

Questions? Email support@rennt.app.