The add_user function creates staff users without validating password strength, checking for duplicate usernames, or verifying the user's identity. An attacker with admin access can create unlimited staff accounts.

**Perspective 1:** The add_user function allows creating/setting passwords without verifying the current password. This enables password reset attacks where an attacker can set a new password without user knowledge. **Perspective 2:** The check_in_or_out function doesn't validate the current state before performing operations. An attacker could potentially manipulate the Checked_In flag to bypass the toggle logic.

URLTokenAuthentication exposes tokens in URL query parameters (GET /api/?key=token). This allows tokens to be logged in server logs, browser history, proxy logs, and server-side caches. Tokens should be passed via Authorization header instead.

SheetPullAPI returns ALL users data without any ownership or permission checks. Any authenticated user can view all members' data including sensitive information. No scope-based or ownership verification.

MeetingPullAPI returns meeting attendance data for all users without ownership verification. Any authenticated user can access all users' check-in/check-out history.

The reset admin action can reset all hours for selected users without verifying the requester has proper authorization. An attacker with admin access can reset hours to manipulate attendance records.

The handle_entry function accepts user_input from POST data with only basic length checking (max 100 chars). No validation is performed on the content format - it could contain SQL injection payloads, XSS vectors, or other malicious content. The input is directly used in database queries and stored in ActivityLog.entered field.

Line 70 performs a database query using user_input directly: models.Users.objects.filter(User_ID=user_input).first(). While Django's ORM provides some protection, this could still be vulnerable to type juggling attacks if User_ID field type doesn't match input type. No validation ensures user_input is numeric before query.

handle_bulk_updates can check-in or check-out ALL users without proper authorization. The -404/+404 commands bypass normal user input validation and can modify all user records.

The handle_bulk_updates function allows checking in ALL users with '-404' command when DEBUG=True. An attacker with admin access can enable DEBUG and check in all users, manipulating attendance records and hours.

**Perspective 1:** POSTGRES_PASSWORD is hardcoded as 'password' in docker-compose.yml. This credential is visible in source control and can be exploited to gain database access. Never commit secrets to version control. **Perspective 2:** POSTGRES_PASSWORD is hardcoded as 'password' in docker-compose.yml. This credential is committed to version control and can be extracted by anyone with repository access. Attack vector: credential theft, database access, lateral movement. **Perspective 3:** The docker-compose.yml contains a comment with a hardcoded password 'password' which could be accidentally committed to version control or discovered during code review. While in a comment, this is still a security concern.

**Perspective 1:** JavaScript code captures username and password from form fields and displays them in a browser alert. This exposes credentials to anyone viewing the admin page, including malicious users and screen readers. **Perspective 2:** JavaScript code exposes username and password in alert dialog: window.alert(`${user}\${pw} COPY THAT DOWN`). Credentials are visible to any user who can access the admin page.