API Security (Input validation, Rate limiting, Auth basics)

Overview

In a real Wedding Planner web application, the REST API is the main entry point for all actions (view weddings, manage guests, RSVP, bookings, availability checks). If API endpoints are not protected, malicious users can read private data, spam requests, or attempt to modify reservations.

Even though our P4 prototype is minimal (Flask REST + SQLite), the same security principles apply in a production environment.

Main risks for our API

If API security is missing, common risks include:

• Unauthorized access to private wedding data (guests, RSVP responses, attendance info)
• Fake RSVP/attendance spam (polluting the database)
• Endpoint abuse (especially availability checks)
• SQL injection attempts through query parameters

In Wedding Planner, the most sensitive resources are:

• Guest lists (Guest table)
• RSVP responses (Event_RSVP table)
• Bookings (Venue_booking, Band_booking, Photographer_booking)

Input validation (most important rule)

Input validation means checking every parameter received from the user before using it in business logic or database queries. This prevents invalid requests, inconsistent data, and accidental crashes.

In our project, validation is especially important for:

• wedding_id, event_id, guest_id (must be positive integers)
• date, start_time, end_time (must be valid formats)
• RSVP status (must be an allowed value)

Example validation rules:

• wedding_id > 0
• end_time > start_time
• RSVP status ∈ {accepted, declined, pending}

Example (pseudo-code):

if wedding_id <= 0:
    return 400 "Invalid wedding_id"

if end_time <= start_time:
    return 400 "Invalid time interval"

Why this matters: Without validation, we can store broken bookings (wrong times) or invalid RSVP values that affect attendance logic.

Parameterized queries (SQL injection prevention)

SQL injection happens when untrusted input becomes part of an SQL query. The correct protection is to always use parameterized queries (never string concatenation).

Unsafe example:

sql = "SELECT * FROM wedding WHERE wedding_id=" + wedding_id

Safe example (conceptual):

SELECT * FROM wedding WHERE wedding_id = ?;

This is critical for endpoints like:

• /weddings/<wedding_id>/events
• /weddings/<wedding_id>/guests
• /availability/venue?venue_id=...&date=...&start=...&end=...

If these endpoints use unsafe query building, attackers can try inputs like:

wedding_id = "1 OR 1=1"

which can expose data from multiple weddings.

Authentication & Authorization (access control basics)

In a full system, not every user should have access to all weddings.

Authentication = who is the user? Authorization = what is the user allowed to do?

Example rules in Wedding Planner:

• Only the owner of the wedding (User.user_id) can view/edit that wedding
• Guests can only RSVP for events they are invited to
• Only wedding owner can view full guest list

Example authorization check (pseudo-code):

if current_user.user_id != wedding.user_id:
    return 403 Forbidden

This prevents the common issue where a user changes the wedding_id in the URL to access another person’s data.

Rate limiting (prevent endpoint abuse)

Rate limiting controls the number of requests per user/IP per time window. This prevents spam, brute-force attempts, and performance degradation.

In Wedding Planner, the most “abusable” endpoint is:

• /availability/venue

Attack scenario: An attacker sends thousands of availability checks per minute which may overload the server.

Example policy:

• 60 requests/minute per IP for /availability/venue
• 30 requests/minute for RSVP-related endpoints

This keeps the system responsive and stable under heavy traffic.

Practical examples connected to Wedding Planner

The following protections directly apply to our system:

• Validate time interval and date format for venue bookings
• Reject RSVP status outside allowed values
• Limit repeated calls to availability endpoint
• Ensure wedding owner can access guest list and attendance overview

Example: protect guest list endpoint

• /weddings/<wedding_id>/guests

Rules:

• wedding_id must be valid integer
• current_user must be wedding owner
• SQL query must be parameterized

Conclusion

API security is essential because it protects the database and prevents abuse of the core system functionalities. For the Wedding Planner system, the most important measures are strict input validation, parameterized queries, access control (auth/authorization), and rate limiting. These practices prevent the most common attacks (SQL injection, data leaks, spam) and ensure the application remains stable and trustworthy.