Security Best Practices

Relevant source files

The following files were used as context for generating this wiki page:

• SECURITY.md
• README.md
• CONTRIBUTING.md
• static/openapi.yaml
• cubic.yaml
• USAGE.md
• STATUS.md

The Smart Absen Face Recognition system incorporates several security measures to ensure data integrity, protect sensitive information, and create a robust, production-ready application. The security architecture focuses on separating configuration from code, validating all inputs, standardizing API responses, and implementing comprehensive error handling and logging. These practices aim to mitigate common web application vulnerabilities such as SQL injection, Cross-Site Scripting (XSS), and information leakage.

The implementation of these security features has significantly improved the system's security posture, raising its score from 6/10 to 9/10 and making it suitable for deployment. The practices are documented across several files, including SECURITY.md, which provides a detailed guide on the improvements, and validators.py, which contains the core input validation logic.

Sources: SECURITY.md, README.md, STATUS.md

1. Configuration and Secret Management

A fundamental security principle applied in this project is the separation of configuration and secrets from the source code. This is achieved using environment variables.

Sources: SECURITY.md:5-16, README.md:100-112

Environment Variables (.env)

All sensitive information, such as database credentials and application secret keys, is managed through a .env file at the project root. The config.py file is responsible for loading these variables using the python-dotenv library. This approach prevents hardcoding secrets into the codebase, which is a critical security risk. A template file, .env.example, is provided to guide developers in setting up their local environment.

Sources: SECURITY.md:5-16, CONTRIBUTING.md:43-51, README.md:100-112

The following diagram illustrates the configuration loading flow.

Sources: SECURITY.md:5-16

The table below lists the key environment variables defined in .env.example.

Variable	Description	Example Value
DB_HOST	The hostname of the MySQL database server.	localhost
DB_USER	The username for the database connection.	root
DB_PASSWORD	The password for the database user.	your-dev-secret-key
DB_NAME	The name of the database to use.	absensi_karyawan_db
SECRET_KEY	A secret key for signing session cookies and other security functions.	your-secret-key
DEBUG	A flag to enable or disable debug mode in Flask.	True

Sources: CONTRIBUTING.md:46-51, SECURITY.md:73-76

2. Input and Data Validation

To protect against invalid data submission, SQL injection, and XSS, the application uses a dedicated validation module, validators.py. This module provides decorators that are applied to Flask routes to validate incoming request data before it is processed.

Sources: SECURITY.md:39-50, CLEANUP_REPORT.md:55-56

Validation Decorators

The system uses function decorators to encapsulate validation logic, keeping the route handlers in app.py clean and focused on business logic.

Key validators include:

• @validate_json: Ensures that the request has the Content-Type: application/json header.
• @validate_employee_data: Validates the fields required for adding a new employee.
• @validate_attendance_data: Validates the data submitted for marking attendance.

Sources: SECURITY.md:42-46

The following diagram shows the request lifecycle with the validation step.

Sources: SECURITY.md:86-93

3. API and Endpoint Security

The project has standardized its API responses and defined security schemes for administrative endpoints. This ensures consistency and proper access control.

Sources: SECURITY.md:25-36, static/openapi.yaml

API Response Standardization

A helper function in helpers.py is used to create consistent JSON responses for all API endpoints. This standard format makes frontend integration easier and provides a clear structure for handling both successful operations and errors.

The standard response format is:

{
    "success": true,
    "status": "success",
    "message": "Operation completed",
    "data": {},
    "timestamp": "2025-12-07T17:45:00"
}

Sources: SECURITY.md:28-36

Authentication

Administrative endpoints are protected via a session cookie-based authentication mechanism. The OpenAPI specification defines this as adminAuth. Access to endpoints like /api/employees (POST, PUT, DELETE) and /api/train_model requires a valid admin session. The default admin credentials are provided for initial setup.

Sources: static/openapi.yaml:273-276, USAGE.md:104-109

The sequence diagram below shows a secure API call to add a new employee.

Sources: static/openapi.yaml:145-167, SECURITY.md:86-93

Rate Limiting (Planned)

The project is prepared for rate limiting using Flask-Limiter. Although not fully implemented, the necessary packages are included, and the documentation provides examples for limiting requests to sensitive endpoints like /api/attendance to prevent abuse.

Sources: SECURITY.md:111-122

4. Error Handling and Logging

The application avoids leaking sensitive information by implementing custom error handlers and structured logging.

Sources: SECURITY.md:18-24, 52-60

Graceful Error Handling

Custom error handlers are registered in app.py for common HTTP error codes such as 403 (Forbidden), 404 (Not Found), and 500 (Internal Server Error). These handlers render a user-friendly templates/error.html page instead of showing default server error pages, which could expose stack traces or configuration details.

Sources: SECURITY.md:18-24

The diagram below shows the error handling process.

Sources: SECURITY.md:21-23

Structured Logging

A rotating file handler is configured to log application events to logs/app.log. The logs have a structured format, and files are rotated once they reach 10MB, with up to 3 backup files kept. This provides a clear audit trail for debugging, monitoring performance, and tracking security-relevant events without overwhelming the file system.

Sources: SECURITY.md:52-60

5. Security Checklist and Future Enhancements

The SECURITY.md file provides a comprehensive checklist that summarizes the current security posture and outlines future work.

Improvement	Status	Impact
Environment Variables	✅ Done	High
Input Validation	✅ Done	High
Error Handling	✅ Done	Medium
Structured Logging	✅ Done	Medium
API Standardization	✅ Done	Medium
CSRF Protection	📋 Ready	High
Rate Limiting	📋 Ready	High
DB Connection Pooling	📋 Ready	Medium
HTTPS in Production	💡 Recommended	High
Password Hashing for Admin	💡 Recommended	High

Sources: SECURITY.md:129-141, 146-155

Conclusion

The Smart Absen project demonstrates a strong commitment to security best practices. By externalizing configuration, enforcing strict input validation, handling errors gracefully, and maintaining detailed logs, the application is well-protected against common threats. The clear documentation and readiness for future enhancements like CSRF protection and rate limiting indicate a mature and security-conscious development process, making the system production-ready.

Sources: SECURITY.md:180-189, STATUS.md:38-39