Security Analysis - adelinaenache/MenuMaker GitHub Wiki

1. Unauthorized Restaurant Access

Risk: An unauthorized user can access and modify restaurant menus or information.

Impact: Restaurants could lose control over their menus, and sensitive information about locations and menus could be exposed. Additionally, customers could receive incorrect or misleading menu information, harming user trust and experience.

Protection Measures: We validate JWT tokens for every request and protect resources through @UseGuards(GqlAuthGuard). Before any modification actions are allowed, we verify that the user has appropriate permissions to ensure only authorized access.

2. User Data Protection

Risk: Exposure of sensitive restaurant and customer data.

Impact: Restaurants may lose access to their accounts, menu and order information could be compromised, and customers might be subjected to phishing attacks.

Protection Measures: Passwords are secured using bcryptjs, with only password hashes stored in the database. We enforce password complexity rules to minimize the risk of weak credentials being exploited.

3. CSRF Attack Protection

Risk: Execution of unauthorized requests on behalf of restaurants.

Impact: This could result in unauthorized menu modifications, the generation of fake QR codes, or changes to restaurant information without consent.

Protection Measures: All requests are protected using JWT tokens passed via the Authorization header. Apollo Client middleware ensures automatic inclusion of these tokens, and backend logic validates them before executing any operation.

4. XSS Attack Protection

Risk: Malicious code injection into restaurant pages.

Impact: This could lead to unauthorized menu changes, data collection from customers, or a degraded user experience due to injected scripts.

Protection Measures: Input fields are sanitized using Formik validation. Furthermore, Next.js and Chakra UI offer built-in protections, and we validate all inputs at the schema level to prevent injection points.

5. SQL Injection

Risk: Exposure of confidential restaurant information.

Impact: Menu and pricing data may be compromised, location information could be leaked, and there is a risk of manipulating order records.

Protection Measures: We use Prisma ORM, which abstracts raw queries and protects against SQL injection by design. All incoming data is validated using class-validator before being processed.

Future Improvements

Rate Limiting Implementation: Currently, our backend is vulnerable to brute force attacks. To mitigate this, we will implement rate limiting to restrict the number of requests a user or IP address can make within a certain timeframe, thereby adding a layer of protection against automated attacks.

Audit Logging Implementation: We do not currently maintain a detailed history of changes made to restaurant menus. Implementing audit logging will allow us to trace modifications, detect suspicious activity, and provide restaurants with an accountability trail for better transparency and support.

HTTPS Implementation: Our backend presently operates over HTTP, leaving us open to man-in-the-middle attacks. Moving to HTTPS is critical. We plan to purchase a domain and configure our load balancers to enforce HTTPS, ensuring that all data in transit is encrypted and secure.

Restrictive CORS Policy: At the moment, we allow requests from all origins, which increases the risk of cross-origin attacks. We intend to configure a stricter CORS policy that only permits trusted domains to interact with our API, thereby reducing the surface area for potential exploits.