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

Overview

In a real Wedding Planner web application, the API is the main entry point for all user actions (view weddings, RSVP, guest management, availability checks). If API endpoints are not protected, attackers can abuse them to read private data, spam requests, or modify bookings.

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

Main risks for our API

If security is missing, possible problems include:

• Unauthorized access to wedding data (guests, RSVPs, bookings)
• Fake RSVPs / attendance spam
• Availability endpoint abuse (hundreds of calls per second)
• SQL injection attempts through query parameters

Input validation (most important rule)

Input validation means checking every value that comes from the user before using it. In our system, this applies especially to parameters such as:

• wedding_id, event_id, guest_id (must be integer)
• date and time intervals for bookings (must be valid and logical)
• RSVP status (must be only allowed values)

Example validation rules in our project:

• wedding_id must be a positive integer
• end_time must be greater than start_time
• RSVP status must be one of: accepted / declined / pending

Example (pseudo-code):

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

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

Why this matters: Without validation, invalid input can crash the API or create inconsistent data (wrong bookings, duplicates, broken rows).

Parameterized queries (protection from SQL injection)

SQL injection happens when attacker input becomes part of the SQL query. The safe way is to use parameterized queries, never string concatenation.

Unsafe example:

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

Safe example:

SELECT * FROM wedding WHERE wedding_id = %s;

In Wedding Planner this is important for endpoints like:

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

Basic authentication & authorization

In a full production application, not everyone should access everything.

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

Example rules in Wedding Planner:

• Only the wedding owner (User) can view/edit that wedding
• Guests can only RSVP via invitation link (limited access)
• Admin can manage venue data

Example check (conceptual):

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

This prevents a user from accessing another user's wedding details just by changing the wedding_id in the URL.

Rate limiting (prevent abuse)

Rate limiting limits the number of requests per user/IP per minute. This is crucial for endpoints that can be abused.

In our system the most "abusable" endpoint is:

• /availability/venue

Attack scenario: Someone sends thousands of availability checks -> server slows down or crashes.

Example policy:

• max 60 requests per minute per IP for /availability/venue

This keeps the API stable even under heavy traffic.

How this connects to our project

For Wedding Planner, API security should focus on:

• Validating booking parameters (date/time overlap)
• Protecting RSVP and attendance updates from spam
• Ensuring only wedding owners can view guest lists
• Preventing abuse of availability checks with rate limiting

Conclusion

API security is essential even for a minimal prototype, because it demonstrates how the system would behave in real-world conditions. For our Wedding Planner application, the most important protections are input validation, parameterized queries, basic access control, and rate limiting. These practices prevent common attacks (SQL injection, data leaks, endpoint abuse) and ensure the system remains stable and trustworthy.