wiki:P9APISecurity

Version 1 (modified by 193284, 7 days ago) ( diff )

--

P9 – API Security (Input Validation, Rate Limiting, Auth Basics)

Overview

In real systems, the database is accessed through an API (backend). Because of that, protecting the API is just as important as designing the database correctly. In Wedding Planner, endpoints such as RSVP updates and booking availability must be protected from invalid input and abuse.

Input validation

Input validation means checking all user input before using it in SQL queries or inserting it in the database.

Why it matters:

  • prevents incorrect data from being stored
  • avoids broken constraints and invalid formats
  • reduces risk of attacks (SQL injection, malicious payload)

Example connected to our project: When calling:

/availability/venue?venue_id=1&date=2026-06-20&start=15:00&end=21:00

The API should validate:

  • venue_id is numeric
  • date is valid YYYY-MM-DD
  • start/end are valid HH:MM
  • end_time > start_time

Pseudo-code example:

if not venue_id.isdigit(): return error("Invalid venue_id")
if not valid_date(date): return error("Invalid date format")
if end <= start: return error("Invalid interval")

Rate limiting

Rate limiting protects the system from too many requests in a short time (spam / brute force).

Why it matters in Wedding Planner:

  • availability checks can be called many times
  • attacker can overload API by repeatedly calling /availability/venue
  • database performance becomes worse under heavy traffic

Example rule:

  • max 60 requests per minute per user/IP

Pseudo-config (conceptual):

limit_requests("/availability/venue", 60 per minute)

Authentication basics

Authentication means verifying who the user is (login/session/token).

Even though our P4 prototype is minimal and REST-based, in a real system:

  • only logged-in users should manage weddings
  • only wedding owner should edit guests / RSVP
  • users should not access other people’s weddings

Example access rule (connected to our project):

GET /weddings/1/guests

Should return data only if:

  • user is logged in
  • user owns wedding_id = 1

Pseudo-code:

if not authenticated(): return 401
if wedding.user_id != current_user.id: return 403

Conclusion

API security protects the database by ensuring that only valid and allowed requests reach the data layer. For Wedding Planner, input validation is critical for correctness (dates/times/IDs), rate limiting protects frequent endpoints like availability checks, and authentication ensures users can only access their own weddings. These practices would be mandatory in a real production implementation of the system.

Note: See TracWiki for help on using the wiki.