Forem: Tagg

Zero-Cost API Infrastructure: Running a DaaS Business on an Idle Server

Tagg — Sun, 05 Apr 2026 08:17:51 +0000

I Had a Server Doing Nothing 22 Hours a Day

I run quantitative trading bots — one for the Korean stock market, one for the US market, one for crypto. They sit on AWS and GCP, watching for signals, executing trades, then going back to sleep.

Most of the time, these servers are idle. And AWS isn't free forever — once the 12-month free tier expired, I was looking at ~$10/month for a t2.micro doing almost nothing for most of the day.

So I asked myself: what if the idle server could pay for itself?

The Idea: Data-as-a-Service on RapidAPI

I'm not a professional developer. My background is in IT architecture — I understand systems, infrastructure, and data flows. But I'd never built an API from scratch before.

What changed was AI-assisted development. With vibe coding (writing in natural language, letting AI generate the code), I could suddenly build things that would have taken me months to learn the traditional way.

I needed a product that:

Runs on the same server as my trading bots without interference
Requires minimal maintenance — no daily babysitting
Has near-zero marginal cost — data I can get for free
Generates recurring revenue — subscriptions, not one-time sales

That pointed me to DaaS (Data-as-a-Service): take publicly available but hard-to-access data, clean it up, and serve it through a REST API on RapidAPI.

Why Korean Data?

Here's something most developers outside Korea don't realize: Korean government data is locked behind walls that have nothing to do with technology.

Government websites are Korean-only
Authentication requires Korean phone numbers or certificates
Data is scattered across multiple agencies in incompatible formats
Documentation is in Korean PDFs, not API specs

If you're a developer in Romania or Brazil trying to check whether a cosmetic ingredient is legal in Korea, you're stuck. Google Translate won't help you navigate a government portal that requires Korean authentication.

This is a moat. Not a technical one — a linguistic and bureaucratic one. And it applies to dozens of Korean datasets that foreign businesses need.

I chose cosmetic ingredients because K-Beauty is a global trend, and regulatory compliance data is something businesses will pay for.

The Stack: Deliberately Boring

I intentionally picked the simplest tools that would work:

Component	Choice	Why
Language	Python	Already using it for trading bots
Framework	FastAPI	Fast, auto-docs, type validation
Database	SQLite	Zero config, read-only, fast for ~22K records
Server	Gunicorn + Uvicorn	Production-ready, 2 workers
Container	Docker	Same environment everywhere
Hosting	AWS EC2 (existing)	Already paying for it
Distribution	RapidAPI	Handles auth, billing, marketing
Monitoring	Telegram alerts	10 alert types, instant notifications

Why SQLite? My data is essentially static — updated monthly. SQLite in read-only mode gives me sub-50ms response times with zero database administration. No connection pools, no migration scripts, no separate database server. The entire database is a single file I can back up with cp.

Why RapidAPI? They take 20% of revenue, which stings. But they handle payment processing, API key management, rate limiting, and put my API in front of millions of developers. For a solo operation, that trade-off makes sense — especially at the start.

Cost Structure: Actually Zero

Item	Monthly Cost
AWS EC2	$0 (shared with trading bots)
Domain	$0 (not purchased yet)
SSL	$0 (RapidAPI handles it)
Database	$0 (SQLite file)
CDN	$0 (not needed)
Monitoring	$0 (Telegram bot API is free)
Total fixed cost	$0

The only cost is RapidAPI's 20% commission — but that only kicks in when I'm making money. Zero risk.

If one PRO subscriber signs up at $29/month, I keep ~$23 after commission. That alone covers the AWS bill when free tier ends.

Resource Sharing: Bots + API on One Server

This was the part I was most worried about. Trading bots need to execute quickly when signals fire. Would the API interfere?

In practice, it's fine:

Trading bots spike CPU for a few seconds during market hours, then sleep
API handles occasional requests throughout the day
Docker isolates the API from the bot processes
SQLite read-only means no disk write contention

The key insight: most API businesses at the early stage get very few requests. I'm not serving 10,000 requests per second — I'm serving maybe 10 per day. The server barely notices.

If traffic ever grows to the point where contention becomes real, that's a champagne problem. I'll spin up a dedicated instance and the API revenue will easily cover it.

What I Built

K-Beauty Cosmetic Ingredients API — 21,796 ingredients with regulatory data across 10 countries.

Four pricing tiers:

Tier	Price	Requests/Month
BASIC	Free	100
PRO	$29	2,000
ULTRA	$79	5,000
MEGA	$199	15,000

The free tier exists for discovery. The paid tiers add more data fields, partial text search, and country-specific regulation data.

Infrastructure That Runs Itself

Since I can't babysit the server, I automated everything I could:

Telegram Alerts (10 types):

Server start/stop
500 errors (instant notification)
Authentication failures
Rate limit violations
New subscriber / cancellation
Daily stats and weekly revenue (planned)

Docker restart policy:

--restart=always

If the container crashes at 3 AM, Docker brings it back up. I find out in the morning from the Telegram alert, but the API was down for maybe 5 seconds.

Server management script:

bash deploy.sh
# 1) Status check
# 2) Restart
# 3) Full redeploy (stop → build → run)
# 4) Live logs
# 5) Stop
# 6) Rollback to previous DB

One script, six options. No remembering Docker commands.

Data updates: Monthly. Download two Excel files from the government open data portal, run a build script, deploy. Total time: about 15 minutes of hands-on work.

Security on a Budget

Just because it's a side project doesn't mean I can skip security:

RapidAPI Proxy Secret — blocks direct access to the server
Per-tier rate limiting — prevents abuse (BASIC: 10/min, MEGA: 40/min)
Input validation — min/max length, type checking, SQL wildcard escaping
Docker non-root user — container runs as apiuser, not root
SQLite read-only mode — even if someone gets in, they can't modify data
HSTS headers — forces HTTPS
Security headers — nosniff, frame deny, XSS protection

Total cost of all this security: $0. It's all code-level.

Lessons After One Month

1. The hardest part isn't building — it's marketing

The API works. The docs are good. The data is solid. But discovery is the bottleneck. RapidAPI's marketplace helps, but it's not magic. I've written blog posts, set up GitHub examples, and optimized my listing. It's a slow grind.

2. Government data is messy but valuable

Cleaning and normalizing data from multiple government sources took far longer than building the API. But that mess is exactly what creates value — if it were clean and easy to access, someone would have done it already.

3. Vibe coding works for real products

I built this entire system — scraper, database builder, API server, deployment pipeline, monitoring — using AI-assisted development. Not as a toy project, but as a production service handling real requests. The key is having enough IT knowledge to architect the system, even if you can't write every line of code from memory.

4. Start with zero fixed costs

If your side project costs $0 to run, you can wait indefinitely for product-market fit. No pressure to monetize immediately. No "burning runway." The server is already there, the tools are free, and RapidAPI only charges when you earn. This patience is a competitive advantage.

Revenue So Far

Let's be honest: close to zero. One free-tier user from Romania tested the API. No paid subscribers yet.

But that's okay. The API is live, the infrastructure runs itself, and my total investment is time — no money. I'll keep improving the product, writing about it, and waiting for the right customers to find it.

The trading bots haven't made me rich either. But between DaaS subscriptions and quantitative trading, I'm building multiple income streams that don't require me to be physically present. That's the goal.

The Framework: Applicable Beyond K-Beauty

The approach works for any closed-ecosystem data:

Find data that's publicly available but practically inaccessible (language barriers, authentication, format issues)
Clean it and serve it through a standard REST API
Host it on infrastructure you're already paying for
Distribute through a marketplace that handles billing
Automate monitoring so you don't have to watch it

Korean business registration data, customs clearance codes, pharmaceutical approvals — there are dozens of datasets locked behind Korean-language government portals that international businesses need.

Each one is a potential API product. Same stack, same server, same pattern.

Try It

If you're curious about the API itself:

🔗 K-Beauty Cosmetic Ingredients API on RapidAPI

📂 GitHub - Example Code

If you're thinking about turning your own idle server into a side business, I'd love to hear your ideas. Drop a comment below.

I Added Regulation Data From 10 Countries to My Cosmetic Ingredients API — Here's What I Found

Tagg — Sat, 04 Apr 2026 15:08:49 +0000

The Backstory

A few weeks ago, I launched a REST API for Korean cosmetic ingredients — 21,000+ ingredients from official Korean government sources, searchable by INCI name, CAS number, and Korean name.

(Original post here)

The API worked. But I kept getting the same question from the cosmetic industry people I talked to:

"Cool, but what about EU regulations? What about China?"

Fair point. If you're formulating cosmetics for global markets, knowing that an ingredient is restricted in Korea is only part of the puzzle. You need to know if it's also banned in the EU, restricted in China, or flagged in ASEAN.

So I went down the rabbit hole.

What I Found: A Hidden Goldmine

Korea's Ministry of Food and Drug Safety (MFDS) doesn't just track Korean regulations. Their database at nedrug.mfds.go.kr contains regulation data for 10 countries, all in one place:

Country	Records
EU	5,301
ASEAN	4,843
China	4,145
South Korea	4,046
Brazil	4,022
Argentina	4,022
Taiwan	2,137
Canada	1,947
Japan	386
USA	111

30,960 regulation records total. Each one tells you whether an ingredient is prohibited or restricted in that country, with detailed conditions — concentration limits, product type restrictions, and usage warnings.

The catch? The data is:

Embedded in HTML pages as JavaScript JSON arrays
Behind a Korean-language interface
Spread across 7,257 individual pages
No API, no download button

Sound familiar?

The Scraping Challenge

7,257 pages. One request at a time.

The MFDS detail pages have an interesting structure. Each page contains a JavaScript variable called arCountry — a JSON array with all the regulation data for that ingredient, across all countries. No AJAX calls needed. One page request = all countries.

But there's a catch within the catch: some ingredients have both restricted and prohibited data, stored in an if/else branch in the JavaScript. A naive regex extraction misses half the data. I had to write a bracket-depth counter to properly extract both arrays.

def extract_json_array(text, start_pos):
    """Bracket counting instead of regex — 
       handles nested brackets in JSON strings"""
    bracket_start = text.index('[', start_pos)
    depth = 0
    for i in range(bracket_start, len(text)):
        if text[i] == '[':
            depth += 1
        elif text[i] == ']':
            depth -= 1
            if depth == 0:
                return text[bracket_start:i + 1]
    return None

Small bug, big difference: one ingredient went from 0 regulation records to 5 after fixing this.

Verifying the Data

Here's the thing about scraping government data from one country about other countries: how do you know it's accurate?

I cross-checked our EU data against the CosIng database — the EU's official cosmetic ingredient database. CosIng publishes their Annex II (prohibited) and Annex III (restricted) lists as downloadable CSVs.

Verification results:

Metric	Result
Total EU records from MFDS	5,248
Matched against CosIng (by CAS number + name)	4,693 (89.4%)
Regulation type accuracy	99.2%
Type mismatches	38

The 38 mismatches weren't errors — they were edge cases where an ingredient is prohibited when used as hair dye but restricted for other uses. Different classification logic, same underlying data.

Good enough to ship.

The New API (v3.0.0)

New endpoint: `/v1/ingredient/{code}/regulations`

import requests

response = requests.get(
    "https://k-beauty-cosmetic-ingredients.p.rapidapi.com/v1/ingredient/9/regulations",
    params={"country": "EU"},
    headers={
        "X-RapidAPI-Key": "YOUR_API_KEY",
        "X-RapidAPI-Host": "k-beauty-cosmetic-ingredients.p.rapidapi.com"
    }
)

print(response.json())

Response:

{
  "success": true,
  "ingredient": {
    "code": 9,
    "kr_name": "리날룰",
    "inci_name": "Linalool"
  },
  "count": 1,
  "available_countries": ["한국", "EU"],
  "data": [
    {
      "country": "EU",
      "regulate_type": "제한",
      "notice_ingr_name": "1,6-Octadien-3-ol, 3,7-dimethyl-",
      "limit_condition": null,
      "source_type": "limit"
    }
  ]
}

One API call. One ingredient. Regulations across multiple countries. No PDF digging, no Google Translate, no guesswork.

Country access by tier

Not everyone needs all 10 countries. So I tiered it:

Tier	Price	Countries	Monthly Requests
BASIC	Free	Ingredients only (no regulations)	100
PRO	$29	South Korea, EU	2,000
ULTRA	$79	+ China, USA, Japan, ASEAN	5,000
MEGA	$199	All 10 countries	15,000

Interesting Findings From the Data

After collecting all 30,960 regulation records, some patterns jumped out:

1. The EU bans the most ingredients

EU leads with 5,301 regulation records. They're the strictest regulatory body for cosmetics — many other countries reference EU decisions when updating their own lists.

2. "Prohibited" doesn't always mean "dangerous"

Some ingredients are prohibited in cosmetics simply because they're classified as pharmaceuticals. Not because they're toxic — because they're too effective and fall under drug regulation instead.

3. The same ingredient, different rules everywhere

Take silver compounds: restricted in Canada (allowed in mouthwash up to 0.04%), but prohibited in the EU when in nano form. A global cosmetic brand needs to track these differences per-market.

4. Most MFDS regulated substances aren't in the KCIA ingredient dictionary

Only 1,269 out of 7,257 MFDS regulated substances matched KCIA ingredients by CAS number. The rest are chemical substances that are banned from cosmetics — they were never cosmetic ingredients to begin with.

Technical Decisions

Why not add all MFDS substances to the main ingredients table?

KCIA tracks what can be used in cosmetics. MFDS tracks what can't be (or has conditions). Mixing them would pollute the ingredient search results with non-cosmetic chemicals. Instead, I kept them in a separate regulations table, linked by CAS number where possible.

Why SQLite, still?

Added 30,960 rows to the existing 21,796-ingredient database. SQLite handles it fine — the regulations table has indexes on ingredient_code, country, and regulate_type. Query time is still under 50ms.

The rate limiting rabbit hole

I wanted per-tier rate limits (BASIC: 10/min, MEGA: 40/min). Turns out the Python slowapi library doesn't support dynamic rate limits based on request context. The decorator function gets called without access to the request object.

Solution: two-layer approach. slowapi handles the global ceiling (40/min), and a custom in-memory counter in the middleware enforces per-tier limits after the tier is detected from the subscription header.

What's Next

Automated weekly updates — KCIA change detection is already built, MFDS full re-scrape takes ~10 hours
API name/description SEO optimization on RapidAPI
More search filters for the regulations endpoint

Try It

The API is live on RapidAPI with a free tier.

🔗 K-Beauty Cosmetic Ingredients API

📂 GitHub - Example Code

If you're building cosmetic tech, regulatory tools, or just curious about what's actually in your skincare products across different countries — give it a shot.

Questions? Drop a comment below.

15 Security Practices I Applied to My FastAPI Side Project

Tagg — Fri, 03 Apr 2026 11:33:16 +0000

⚠️ Disclaimer
These are practical measures I applied to my side project.
For enterprise-grade security, consult professionals.

Why This Post?

I recently launched a K-Beauty Cosmetic Ingredients API on RapidAPI. Before going live, I spent significant time hardening security.

This post shares 15 practical security measures I implemented, with:

✅ Real code examples
✅ OWASP Top 10 mapping
✅ Lessons learned

Whether you're deploying on RapidAPI, AWS, or anywhere else — these patterns apply.

Authentication & Access Control
Server Hardening
Database Security
Monitoring & Alerting
Resilience & Error Handling
OWASP Top 10 Mapping
Lessons Learned

1. Authentication & Access Control

1.1 RapidAPI Proxy Secret Validation

RapidAPI acts as a proxy. But what stops someone from calling your server directly?

Proxy Secret — a shared secret that only RapidAPI knows.

from fastapi import Request, HTTPException

RAPIDAPI_PROXY_SECRET = os.environ.get("RAPIDAPI_PROXY_SECRET")

@app.middleware("http")
async def verify_rapidapi_proxy(request: Request, call_next):
    # Skip for health checks
    if request.url.path == "/health":
        return await call_next(request)

    # Verify secret
    proxy_secret = request.headers.get("X-RapidAPI-Proxy-Secret")
    if proxy_secret != RAPIDAPI_PROXY_SECRET:
        raise HTTPException(status_code=403, detail="Forbidden")

    return await call_next(request)

🔐 OWASP A01: Broken Access Control — Direct access blocked.

1.2 Tier-Based Access Control

Different subscription tiers get different features:

@app.middleware("http")
async def extract_tier(request: Request, call_next):
    tier_header = request.headers.get("X-RapidAPI-Subscription", "BASIC")
    request.state.tier = tier_header.upper()
    return await call_next(request)

# In endpoint:
def search_partial(request: Request, q: str):
    if request.state.tier == "BASIC":
        raise HTTPException(
            status_code=403, 
            detail="Partial search requires PRO or ULTRA tier"
        )
    # ... continue

Tier	Features
BASIC	Exact search only
PRO	+ Partial search, more fields
ULTRA	+ All fields, highest limits

1.3 Rate Limiting with SlowAPI

Prevent abuse and ensure fair usage:

from slowapi import Limiter
from slowapi.util import get_remote_address

limiter = Limiter(key_func=get_remote_address)
app.state.limiter = limiter

@app.get("/v1/ingredient/inci")
@limiter.limit("60/minute")
def search_by_inci(request: Request, q: str):
    # ...

🔐 OWASP A07: Identification and Authentication Failures — Brute force prevention.

2. Server Hardening

2.1 Docker Non-Root User

Never run containers as root:

# Create non-root user
RUN groupadd -r apigroup && useradd -r -g apigroup apiuser

# Set ownership
COPY --chown=apiuser:apigroup . /app

# Switch to non-root user
USER apiuser

CMD ["gunicorn", "main:app", "-w", "2", "-k", "uvicorn.workers.UvicornWorker"]

🔐 OWASP A04: Insecure Design — Principle of least privilege.

2.2 Sensitive File Permissions

.env files should only be readable by owner:

chmod 600 config/.env

-rw-------  1 ubuntu ubuntu  .env    # Only owner can read/write

🔐 OWASP A05: Security Misconfiguration — Sensitive data protected.

2.3 Environment Separation

Different configs for different environments:

ENV = os.environ.get("ENV", "dev")

if ENV == "prod":
    DEBUG = False
    LOG_LEVEL = "WARNING"
else:
    DEBUG = True
    LOG_LEVEL = "DEBUG"

2.4 HSTS Header

Force HTTPS connections:

@app.middleware("http")
async def add_security_headers(request: Request, call_next):
    response = await call_next(request)
    response.headers["Strict-Transport-Security"] = "max-age=31536000; includeSubDomains"
    return response

🔐 OWASP A02: Cryptographic Failures — Encrypted transport enforced.

3. Database Security

3.1 OS-Level Read-Only Mode

API only reads data. Why allow writes?

Instead of relying on SQLite's PRAGMA query_only, I used OS-level read-only mode via URI parameter — a more robust approach:

def get_db():
    # file: URI with ?mode=ro enforces read-only at OS level
    conn = sqlite3.connect(
        f"file:{DB_PATH}?mode=ro",
        uri=True,
        timeout=5.0
    )
    return conn

This is stronger than PRAGMA query_only because:

OS-level enforcement — even if SQLite has a bug, the OS blocks writes
Cannot be bypassed — no way to disable via SQL commands

🔐 OWASP A08: Software and Data Integrity Failures — No unauthorized modifications.

3.2 Parameterized Queries

Never concatenate user input into SQL:

# ❌ BAD - SQL Injection vulnerable
cursor.execute(f"SELECT * FROM ingredients WHERE name = '{user_input}'")

# ✅ GOOD - Parameterized
cursor.execute("SELECT * FROM ingredients WHERE name = ?", (user_input,))

🔐 OWASP A03: Injection — SQL injection prevented.

3.3 LIKE Wildcard Escaping

User input in LIKE queries can abuse wildcards (%, _):

def escape_like_wildcards(value: str) -> str:
    """Escape LIKE wildcards to prevent injection."""
    return value.replace("\\", "\\\\").replace("%", "\\%").replace("_", "\\_")

# Usage
escaped_q = escape_like_wildcards(user_input)
cursor.execute(
    "SELECT * FROM ingredients WHERE inci_name LIKE ? ESCAPE '\\\\'",
    (f"{escaped_q}%",)
)

3.4 Query Timeout

Prevent long-running queries from blocking:

conn = sqlite3.connect(f"file:{DB_PATH}?mode=ro", uri=True, timeout=5.0)

4. Monitoring & Alerting

4.1 Telegram Alerts on Server Start

Know immediately when your server restarts:

def alert_server_started(version: str, env: str, db_count: int):
    message = f"""
🚀 <b>API Server Started</b>
├ Version: {version}
├ Environment: {env}
├ DB Records: {db_count:,}
└ Time: {datetime.now().strftime('%Y-%m-%d %H:%M:%S')}
"""
    send_telegram_message(message)

4.2 Real-Time Error Alerts

500 errors go straight to Telegram:

@app.exception_handler(Exception)
async def global_exception_handler(request: Request, exc: Exception):
    alert_error(
        endpoint=request.url.path,
        error_type=type(exc).__name__,
        error_message=str(exc)[:500]
    )
    return JSONResponse(
        status_code=500,
        content={"detail": "Internal server error"}
    )

🔐 OWASP A09: Security Logging and Monitoring Failures — Real-time visibility.

4.3 Preventing Duplicate Alerts

Multiple Gunicorn workers = multiple startup alerts? Not anymore:

lock_file = os.path.join(LOG_DIR, ".startup_alert_lock")

try:
    # Clean up stale lock files (server restart case)
    # Race Condition defense: ignore if another worker deleted it first
    try:
        if os.path.exists(lock_file):
            file_age = time.time() - os.path.getmtime(lock_file)
            if file_age > 10:
                os.remove(lock_file)
    except OSError:
        pass  # Another worker deleted it first — continue

    # Atomic file creation - only first worker succeeds
    fd = os.open(lock_file, os.O_CREAT | os.O_EXCL | os.O_WRONLY)
    os.close(fd)
    alert_server_started(version, env, count)  # First worker sends
except FileExistsError:
    pass  # Other workers skip

This handles:

TOCTOU (Time-of-check to time-of-use) — Atomic O_EXCL operation
Race conditions — OSError catch for concurrent access

4.4 Structured JSON Logging

Logs that are easy to parse and analyze:

import logging
import json

def log_api_request(endpoint, query, status_code, response_time_ms):
    log_entry = {
        "timestamp": datetime.utcnow().isoformat(),
        "endpoint": endpoint,
        "query": query,
        "status_code": status_code,
        "response_time_ms": response_time_ms
    }
    logger.info(json.dumps(log_entry))

5. Resilience & Error Handling

5.1 Graceful Logging Failures

Log failures shouldn't crash your API:

async def safe_log(request, endpoint, query, status_code):
    try:
        await asyncio.to_thread(
            log_api_request, request, endpoint, query, status_code
        )
    except Exception:
        pass  # Log failure doesn't affect API response

5.2 Telegram Retry Logic

Network is unreliable. Retry with backoff:

from urllib3.util.retry import Retry
from requests.adapters import HTTPAdapter

retry_strategy = Retry(
    total=3,
    backoff_factor=0.5,           # 0.5s, 1s, 2s
    status_forcelist=[429, 500, 502, 503, 504],
    respect_retry_after_header=True  # Honor 429 Retry-After
)

session = requests.Session()
session.mount("https://", HTTPAdapter(max_retries=retry_strategy))

5.3 Input Sanitization for Alerts

User input in Telegram messages? Escape it:

import html

def alert_error(endpoint: str, error_message: str):
    safe_message = html.escape(error_message)[:4000]  # Telegram limit
    send_telegram_message(f"Error at {endpoint}: {safe_message}")

5.4 Docker Auto-Restart

Container crashes? Auto-recover:

docker run -d \
  --restart=always \
  --name myapi \
  myapi:latest

5.5 Health Check Endpoint

For load balancers and monitoring:

@app.get("/health")
def health_check():
    return {
        "status": "healthy",
        "version": "2.3.0",
        "timestamp": datetime.utcnow().isoformat()
    }

HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 \
  CMD curl -f http://localhost:8000/health || exit 1

6. OWASP Top 10 Mapping

Here's how our security measures map to OWASP Top 10 (2021):

OWASP	Risk	Our Mitigation
A01	Broken Access Control	✅ Proxy Secret, Tier-based access
A02	Cryptographic Failures	✅ HSTS header, HTTPS enforced
A03	Injection	✅ Parameterized SQL, LIKE escaping
A04	Insecure Design	✅ Non-root Docker, read-only DB
A05	Security Misconfiguration	✅ .env permissions, env separation
A06	Vulnerable Components	⚠️ Regular dependency updates needed
A07	Auth Failures	✅ Rate limiting, secret validation
A08	Data Integrity	✅ OS-level read-only database
A09	Logging Failures	✅ JSON logging, Telegram alerts
A10	SSRF	➖ N/A (no external requests)

Coverage: 9/10 categories addressed ✅

7. Lessons Learned

1. Security is Layers

No single measure is enough. Defense in depth:

Network → Proxy Secret
Application → Rate limiting, input validation
Data → Read-only, parameterized queries
Infrastructure → Non-root, auto-restart
Monitoring → Real-time alerts

2. Fail Gracefully

Security logging shouldn't break your API. Wrap everything in try-except.

3. Assume Breach

Design as if attackers will get in:

Read-only database (can't modify)
Non-root container (limited damage)
Monitoring (you'll know quickly)

4. Automate Everything

Auto-restart on crash
Auto-retry on network failure
Auto-alert on errors

5. Test Your Security

Before launch:

# Test direct access (should fail)
curl http://your-server:8000/v1/stats
# Expected: 403 Forbidden

# Test with valid secret (should work)
curl -H "X-RapidAPI-Proxy-Secret: your-secret" http://your-server:8000/v1/stats
# Expected: 200 OK

Wrapping Up

Security isn't a feature — it's a foundation. These 15 measures took extra time upfront, but give me confidence that the API can handle production traffic safely.

Resources:

Try the API

If you're curious about the API itself:

🔗 K-Beauty Cosmetic Ingredients API

📂 GitHub - Example Code

Questions about any of these security measures? Drop a comment below!

I Built an API for 21,000+ Korean Cosmetic Ingredients — Here's Why

Tagg — Wed, 01 Apr 2026 13:32:33 +0000

The Problem Nobody Talks About

If you've ever tried to check whether a cosmetic ingredient is legal in South Korea, you know the pain:

🇰🇷 Government websites only in Korean
📄 Data buried in PDFs, not databases
🔍 No search functionality
🚫 No official API

For cosmetic brands trying to enter the Korean market, this means hours of manual research, expensive consultants, or just... guessing.

I decided to fix this.

What I Built

K-Beauty Cosmetic Ingredients API — A REST API with:

✅ 21,796 ingredients from official Korean sources
✅ INCI names, CAS numbers, Korean translations
✅ Regulatory status (Prohibited / Restricted / Not Listed)
✅ Concentration limits and conditions
✅ Fast JSON responses (<50ms)

Data comes directly from:

MFDS (Ministry of Food and Drug Safety) — Korea's FDA
KCIA (Korea Cosmetic Industry Association)

Quick Example

Want to check if Retinol is restricted in Korea?

import requests

response = requests.get(
    "https://k-beauty-cosmetic-ingredients.p.rapidapi.com/v1/ingredient/inci",
    params={"q": "retinol"},
    headers={
        "X-RapidAPI-Key": "YOUR_API_KEY",
        "X-RapidAPI-Host": "k-beauty-cosmetic-ingredients.p.rapidapi.com"
    }
)

data = response.json()
print(data)

Response:

{
  "success": true,
  "count": 3,
  "data": [
    {
      "inci_name": "RETINOL",
      "kr_name": "레티놀",
      "cas_numbers": "68-26-8",
      "regulation_status": "Restricted",
      "purposes": "Skin conditioning"
    }
  ]
}

Now you know: Retinol is restricted (allowed with conditions) in Korean cosmetics. No PDF digging required.

Who Is This For?

User	Use Case
🧪 Cosmetic Formulators	Check ingredients before formulating
📋 Regulatory Consultants	Speed up compliance audits
🏭 Manufacturers	Validate formulations for Korea export
📱 App Developers	Build ingredient scanner apps
🛒 E-commerce	Show safety info on product pages

API Endpoints

Endpoint	Description
`/v1/ingredient/inci?q=`	Search by INCI name
`/v1/ingredient/cas?q=`	Search by CAS number
`/v1/ingredient/kr?q=`	Search by Korean name
`/v1/ingredient/search?q=`	Partial text search
`/v1/ingredient/status?s=`	Filter by regulatory status
`/v1/stats`	Database statistics

Tech Stack

For those curious about how it's built:

Backend: Python, FastAPI
Database: SQLite (read-only mode)
Server: Gunicorn + Uvicorn workers
Infrastructure: AWS EC2, Docker
Monitoring: Telegram alerts
Distribution: RapidAPI
Security: OWASP Top 10 hardened (Rate Limiting, Input Validation, LIKE Wildcard Escaping, Proxy Secret)

Why SQLite?

The data is essentially static (updated monthly). SQLite in read-only mode gives us:

Zero configuration
Fast reads
No separate database server
Easy backups

For a read-heavy API with ~22K records, it's perfect.

Lessons Learned

1. Government Data is Messy

Scraping and normalizing data from multiple sources took 10x longer than building the API itself.

2. B2B > B2C for Niche APIs

Consumer apps want "safety scores." Businesses want regulatory compliance data. They're willing to pay for it.

3. Documentation Matters

Good docs = fewer support questions = more time for features.

Try It Free

The API is live on RapidAPI with a free tier (100 requests/month).

🔗 K-Beauty Cosmetic Ingredients API

📂 GitHub - Example Code

What's Next?

[ ] Monthly data updates
[ ] More search filters
[ ] Batch lookup endpoint
[ ] Python/JS SDK packages

Questions?

Drop a comment below or reach out on RapidAPI. Happy to help!

If you're working on cosmetic tech or regulatory compliance tools, I'd love to hear about your use case.

Forem: Tagg

Zero-Cost API Infrastructure: Running a DaaS Business on an Idle Server

I Had a Server Doing Nothing 22 Hours a Day

The Idea: Data-as-a-Service on RapidAPI

Why Korean Data?

The Stack: Deliberately Boring

Cost Structure: Actually Zero

Resource Sharing: Bots + API on One Server

What I Built

Infrastructure That Runs Itself

Security on a Budget

Lessons After One Month

1. The hardest part isn't building — it's marketing

2. Government data is messy but valuable

3. Vibe coding works for real products

4. Start with zero fixed costs

Revenue So Far

The Framework: Applicable Beyond K-Beauty

Try It

I Added Regulation Data From 10 Countries to My Cosmetic Ingredients API — Here's What I Found

The Backstory

What I Found: A Hidden Goldmine

The Scraping Challenge

7,257 pages. One request at a time.

Verifying the Data

Verification results:

The New API (v3.0.0)

New endpoint: /v1/ingredient/{code}/regulations

Country access by tier

Interesting Findings From the Data

1. The EU bans the most ingredients

2. "Prohibited" doesn't always mean "dangerous"

3. The same ingredient, different rules everywhere

4. Most MFDS regulated substances aren't in the KCIA ingredient dictionary

Technical Decisions

Why not add all MFDS substances to the main ingredients table?

Why SQLite, still?

The rate limiting rabbit hole

What's Next

Try It

15 Security Practices I Applied to My FastAPI Side Project

Why This Post?

Table of Contents

1. Authentication & Access Control

1.1 RapidAPI Proxy Secret Validation

1.2 Tier-Based Access Control

1.3 Rate Limiting with SlowAPI

2. Server Hardening

2.1 Docker Non-Root User

2.2 Sensitive File Permissions

2.3 Environment Separation

2.4 HSTS Header

3. Database Security

3.1 OS-Level Read-Only Mode

3.2 Parameterized Queries

3.3 LIKE Wildcard Escaping

3.4 Query Timeout

4. Monitoring & Alerting

4.1 Telegram Alerts on Server Start

4.2 Real-Time Error Alerts

4.3 Preventing Duplicate Alerts

4.4 Structured JSON Logging

5. Resilience & Error Handling

5.1 Graceful Logging Failures

5.2 Telegram Retry Logic

5.3 Input Sanitization for Alerts

5.4 Docker Auto-Restart

5.5 Health Check Endpoint

6. OWASP Top 10 Mapping

7. Lessons Learned

1. Security is Layers

2. Fail Gracefully

3. Assume Breach

4. Automate Everything

5. Test Your Security

Wrapping Up

Try the API

I Built an API for 21,000+ Korean Cosmetic Ingredients — Here's Why

The Problem Nobody Talks About

What I Built

New endpoint: `/v1/ingredient/{code}/regulations`