What MoodFood asks for, stores, and protects.

Question 1

What access do we ask for, and why?

Access	Why
Camera	To scan what's in your fridge (Fridge Scanner) and to photograph a cookbook page or finished dish for Recipe Import.
Photo library	To pick an existing photo for the same two features, instead of taking a new one.
Push notifications	Meal reminders, new recipe suggestions, and Family Plan invite/voting alerts. Optional — declining still lets you use the app.
Apple Sign-In	An optional sign-in method alongside email and phone/OTP login.

Source: frontend/app.json permission declarations, and the camera/photo-library request calls in frontend/app/fridge.tsx and frontend/app/import.tsx.

Question 2

Do we store data — and if so, what, and for how long?

Yes. Here's what's actually persisted, by category:

• Account: email or phone number, name, dietary and cuisine preferences — kept while your account exists.
• Conversations: your AI chef chat history, including diabetes-focused chats.
• Recipes: saved recipes, anything you import (by link, photo, video, or text), ratings, and usage history.
• Fridge Scanner: each photo you scan is stored together with its results, not just the results.
• Meal planning: weekly meal plans, diabetes-specific plans and preferences.
• Shopping lists built from your plans.
• Family Plan: family membership, invitations, and voting-session data, while a Family Plan is active.
• Billing: subscription status and transaction records — never raw card numbers, which go straight to Razorpay or Stripe and never touch our servers.
• Auth & security bookkeeping: login events, OTP verification records, and rate-limit counters.

Source: every MongoDB collection referenced across backend/routes/ (39 collections total), cross-checked for expireAfterSeconds / TTL indexes — only refresh_tokens has one, in backend/routes/deps.py.

Question 3

If a user deletes their account, does that data go away?

If you want your account and data removed, email support@moodfood.in and we'll process it directly. Building a self-serve, in-app deletion flow (with the same protections most apps offer — a short grace period before permanent removal) is on our roadmap; this page will be updated the day it ships.

Source: no match for account-deletion logic anywhere in backend/, frontend/, or web_frontend_old/ as of this review.

Question 4

Is user data secure?

As with any product, "secure" isn't a permanent, absolute state — it's an ongoing practice. Our team ran an internal 47-point security audit and documented, honestly, both what's covered and what's intentionally left as backlog rather than rushed (see below). Nothing was hidden or glossed over in that process.

Question 5

What security measures do we have?

• Password hashing: bcrypt with a per-password salt — plain-text passwords are never stored, and password hashes are never returned in any API response.
• Authentication tokens: short-lived signed JWT access tokens plus rotating refresh tokens; every request verifies both the signature and expiry, with the signing algorithm pinned so a forged/unsigned token can't slip through.
• Brute-force defense: tighter rate limits specifically on login, OTP, registration, and token-refresh — separate from general traffic limits.
• Abuse protection: a sliding-window request limit per IP address blocks scraping, credential-stuffing, and signup-spam bursts without affecting normal use.
• Request hardening: dangerous HTTP methods are blocked, method-override header spoofing is rejected, request-smuggling patterns are rejected, request size is capped, and secrets/tokens passed in a URL are refused outright (they must go in the auth header, where they're not logged in plain URLs).
• SSRF protection: when you import a recipe from a URL, that URL is checked to block requests aimed at internal/private network addresses.
• Admin access control: admin-only actions are gated behind an explicit role check, and the profile-update endpoint can't be used to grant yourself admin rights.
• Cost-abuse limits: AI image generation (an expensive operation) is capped per user per day to prevent runaway costs from being triggered maliciously.

Source: backend/security_middleware.py, backend/routes/deps.py, and the team's own memory/SECURITY_47_VECTORS_STATUS.md audit log.

Question 6

If we use video and audio, what are they for?

Audio — currently one-way, app to you. In hands-free Cooking Mode, each recipe step is converted to spoken audio (an AI-generated voice) so you can cook without touching your phone. Today, the mobile app only speaks to you — it does not request microphone access or record you. A separate voice-transcription capability (converting your spoken words to text via OpenAI's Whisper model) exists in the backend and is used elsewhere in the product, but isn't currently wired into a microphone permission on mobile. Where it is used, the audio clip is sent to OpenAI for transcription and isn't kept afterward — only the resulting text is stored.

Video. MoodFood can import a recipe from a YouTube video link. We don't download or store the video itself — its content is processed to extract the recipe, and only the resulting text recipe is saved.

We don't use audio or video for anything beyond these two purposes — no ambient listening, no background recording, no video calls.

Source: backend/routes/mobile_voice.py, backend/voice_service.py, backend/routes/voice.py, and the video-import path in backend/routes/import_recipe.py.