# Insecure vs Secure: Same App, Two Builds

> The same mobile app on Azure, built two different ways.

- **Format:** short video, 8 steps, ~25 seconds
- **Topic:** The same mobile app built two ways on Azure — straight to the database with a key in the app, versus Front Door, your own API and a private database — with six events played through both architectures side by side.
- **Author:** Suthahar Jegatheesan (MSDEVBUILD)
- **Category:** Azure · Azure Security
- **Published:** 2026-08-19
- **Tags:** azure, security, systemdesign, cloudarchitecture, mobilesecurity, apisecurity, azuresql, dotnet, softwarearchitecture, devsecops, backenddeveloper, microsoftazure, az305, msdevbuild
- **Canonical URL:** https://blog.msdevbuild.com/shorts/insecure-vs-secure-architecture/

---
## What you'll learn

- Why the insecure architecture ships first — it genuinely works
- The six moments where the two designs stop behaving the same
- Why the difference only shows up when something goes wrong

## Understand it one step at a time

### 1. Two ways to build it

Top: the app talks straight to the database. Bottom: it never does. Both compile, both demo fine — only one survives an attacker.

### 2. A real customer: both work

A real customer opens the app and it just works, on both designs. This is exactly why the risky one ships — nothing looks wrong yet.

### 3. Someone unzips the app

Unzip the package: top hands over a database connection string. Bottom hands over nothing, because the app never held one.

### 4. He dials the database

He dials the database directly. Top answers, because it has a public address. Bottom has no address to even attempt.

### 5. He asks for another user’s order

He asks for another user’s order by id. Top has no owner check to fail it. Bottom filters every query by the validated token.

### 6. Now replace the secret

Rotating a leaked secret on top means a new build and a store review. On bottom it’s one command, and nobody’s app breaks.

### 7. One design cannot be fixed

The top design can’t be patched into the bottom one — the database itself has to lose its public address, which changes the shape.

### 8. Both work. One survives

Identical behaviour for every real customer, right up until the day something goes wrong — that’s the only day the difference shows.

---

## The takeaway

**Both work. Only one survives.**

The insecure one is not slower or buggier — it just cannot be fixed without a new app release.