Platform Security Assessment
Application Security
Assessment Report
This report summarises the security posture of the ScholarMeet platform across authentication, authorisation, data handling, file uploads, payment data and privacy controls, verified against the application source code.
Report Ref
SM-SEC-2026-08
Assessment Date
25 August 2026
Assessment Type
Internal Assessment
Scope & Method
This assessment reviewed the ScholarMeet application source code as at 25 August 2026, covering 21 controls across 7 domains. Each control listed in this report was confirmed present in the implementation; the file that evidences it is cited alongside it.
This is an internal assessment carried out by review of the application source. It is not a penetration test, not a third-party audit, and not a certification against any external standard.
Its scope is the application layer. Infrastructure, hosting, network and transport-layer protections are maintained separately and were not in scope. Controls not listed in this report should be read as not claimed rather than as assessed and passed.
AUTH
6 controls
ACCESS
2 controls
DATA
4 controls
APP
2 controls
FILE
3 controls
PAY
2 controls
PRIV
2 controls
Authentication & Session Management
How identity is established and how a signed-in session is protected for its lifetime.
Passwords are hashed with bcrypt on assignment and are never written or logged in plaintext. The platform cannot reveal a password, only verify one.
App\Models\User โ 'password' => 'hashed'
A fresh session identifier is issued on every successful authentication, including the Google OAuth callback, so a session ID captured before sign-in cannot be reused after it.
AuthController โ session()->regenerate() on all login paths
Session cookies are issued HttpOnly, placing them out of reach of page JavaScript, and SameSite=Lax, so browsers withhold them on cross-site requests.
config/session.php
Email codes are drawn from a cryptographic random source, expire ten minutes after issue, and are destroyed on use or when superseded, so a code cannot be replayed.
App\Models\Otp; AuthController
The Google sign-in callback validates the session-bound state parameter, so a login flow begun by an attacker cannot be completed against another person's session.
Laravel Socialite, session-backed state
Password reset and password change endpoints are rate limited per client to blunt automated guessing.
routes/auth.php, routes/settings.php โ throttle:6,1
Authorisation & Access Control
How the platform decides what an authenticated person is allowed to reach.
Administrative, host and organization route groups are gated by dedicated middleware that rejects unauthorised roles with a 403 before the controller runs.
App\Http\Middleware โ Admin, Host, HostOrAdmin
Delegated administrators hold explicit per-module grants rather than blanket access, so an account can be scoped to only the sections its holder needs.
SubAdminModule middleware; user_permission_module
Data Handling
How records are written, queried, and kept out of responses that should not carry them.
Every model declares exactly which attributes may be populated from request input, so a crafted submission cannot write to a column that was never part of the form.
protected $fillable on all models in App\Models
Password hashes, remember-me tokens and third-party provider identifiers are excluded from serialisation and cannot surface in an API response or page payload.
App\Models\User โ $hidden
Data access runs through the query builder, and hand-written SQL fragments bind user input as parameters rather than concatenating it into the statement.
Eloquent query builder across App\Http\Controllers
Cookie values are encrypted and signed, so they cannot be read or altered by the client. Two non-sensitive interface preferences are exempt by design.
bootstrap/app.php โ encryptCookies
Application Hardening
Protections against requests and content that arrive looking legitimate.
State-changing requests are verified against a session-bound anti-forgery token site-wide, so another origin cannot cause an action on a signed-in person's behalf.
bootstrap/app.php โ ValidateCsrfTokens
Editorial rich text is filtered through an allow-list on the server before storage, removing scripts, event-handler attributes and javascript: URLs irrespective of what the client submitted.
HTMLPurifier via config/purifier.php
File Upload Handling
How documents, manuscripts and images submitted to the platform are accepted and stored.
Every upload endpoint validates the submitted file against an explicit list of permitted types before the file is accepted.
mimes: rules across App\Http\Requests
Each upload endpoint enforces a maximum file size appropriate to what it accepts, bounding resource consumption per request.
max: rules across App\Http\Requests
Stored files are named by the platform rather than by the browser, so a submitted filename cannot influence the path a file is written to.
App\Services\MediaService
Payment Data
What the platform does and does not hold in connection with conference fees.
The platform stores no card numbers, security codes, expiry dates or cardholder names. No column of that kind exists in the schema and no card-processing gateway is integrated.
Verified absent across all migrations and models
Where a payment receipt is scanned to read its details, that processing runs in the submitting browser; the image is not transmitted to a third-party recognition service.
Client-side OCR in the attendee payment flow
Privacy Controls
The control a person retains over their own record.
Account deletion is available from profile settings, is confirmed with the account password, and invalidates the session on completion.
Settings\ProfileController::destroy
Newsletter messages carry a tokenised unsubscribe link that takes effect immediately without requiring the recipient to sign in.
NewsletterController::unsubscribe
Statement of limitations. A security assessment describes a system at a point in time. This report reflects the codebase on 25 August 2026 and does not warrant the absence of vulnerabilities. It is issued by ScholarMeet about its own platform and carries no external accreditation. Next scheduled review: 25 August 2027.
ScholarMeet
Issuing Party
Internal Source-Code Review
Assessment Method
Internal application security assessment ยท Ref SM-SEC-2026-08 ยท Current version at https://www.scholarmeet.com/security-report
Report a vulnerability: hello@scholarmeet.com