Afterwords

This app is already shut down. It was hosted only for presentation purposes, but besides that, it is unsafe and inefficient to host it.
It would require securing by:

• applying an API between frontend and backend communication.
• limiting the rate of possible requests per minute.
• validating the input from files, URLs, and text.

And for sure, some other improvements as well.

The transcript feature came from Alibaba Cloud because it was the main goal of the project. However, to keep the service, I would have to migrate it to another cloud provider because I’m not confident in Alibaba Cloud. If moving the project to, for example, GCP, it would be even easier to create it from scratch.

---

Future steps to run this page publicly is to harder the app just it. Then hosting.

What are insecurities of hosting this site publicly?

I found several concrete risks already; I’ll inspect the two utility modules next to confirm network and file-handling exposure before summarizing severity-ranked issues.

I’m pulling exact line numbers now so you get a precise risk list tied to the current code.

If you host this publicly in the current state, these are the main security risks, highest first:

1. Unauthenticated public API abuse and bill shock
   Anyone can call transcription and TTS endpoints, consume your Alibaba quota, and run up cost because there is no auth, API key check, or rate limiting in routes.py:36, routes.py:65, and routes.py:113.

2. SSRF risk through URL transcription
   The URL endpoint accepts user-supplied URLs and server-fetches them, which can be used to probe internal network resources or metadata endpoints if deployed in cloud/private networks: routes.py:65, routes.py:77, speech_to_text.py:60.

3. Token and app key sent over plain HTTP to speech API
   Speech-to-text uses HTTPConnection (not HTTPSConnection), so token and payload can be intercepted in transit: speech_to_text.py:22.
   Also app key is in query string, which increases chance of leakage in logs/proxies: speech_to_text.py:49.

4. Path traversal / file overwrite via uploaded filename
   Uploaded filename is used directly when building path; crafted names can escape uploads or overwrite files depending on OS/path handling: routes.py:49, routes.py:50, routes.py:51.

5. Sensitive upstream error leakage
   Raw provider error details are returned to clients, which can leak backend/internal information useful to attackers: routes.py:167, routes.py:168.

6. Public-facing dev server usage risk
   Running with Flask built-in server from app.run is not hardened for internet exposure and lacks production protections by default: main.py:6.

What this means in practice:
Public deployment today is unsafe without at least auth + rate limiting + SSRF controls + HTTPS-only upstream calls.

Fastest hardening order:

1. Add API authentication and per-IP/per-key rate limiting.
2. Restrict transcribe-url to allowlisted domains or block private/internal IP ranges.
3. Switch STT call to HTTPSConnection and avoid putting app key in URL query where possible.
4. Sanitize filenames with secure_filename and randomize storage names.
5. Return generic errors to clients, keep detailed errors only in server logs.
6. Run behind Gunicorn + reverse proxy with TLS.

If you want, I can implement the top 3 fixes directly in this repo next.

How could I host this app? Is it possible with Netlify?

Short answer: Netlify is not a good fit for this Flask app as-is.

Why:

1. Netlify free is primarily for static sites and serverless functions.
2. Your app is a long-running Flask backend with file uploads, external API calls, and temporary file handling.
3. You could force it into Netlify Functions, but you will hit function timeout and execution limits quickly for audio transcription workloads.

Best practical setup on free tier:

1. Keep your blog/frontend on Netlify.
2. Deploy Flask backend on a Python-friendly host:
   1. Render (easy Flask deploy, free tier with sleep/cold starts)
   2. Railway (easy, but free credits/limits change over time)
   3. Fly.io (more setup, good control)
   4. PythonAnywhere (simple for small Flask apps)

Recommended:

1. Use Render for backend.
2. Keep .env secrets in Render environment variables (never in repo).
3. Point your Netlify frontend to the Render backend URL.
4. Add rate limiting/auth before making it public.