Scholar Meet
Trust Center
SM-SEC-2026-08
ScholarMeet Academic Conference Platform

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

AUTH

Authentication & Session Management

How identity is established and how a signed-in session is protected for its lifetime.

AUTH-01 Password storage Implemented

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'

AUTH-02 Session fixation prevention Implemented

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

AUTH-03 Session cookie attributes Implemented

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

AUTH-04 One-time sign-in codes Implemented

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

AUTH-05 OAuth state validation Implemented

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

AUTH-06 Credential endpoint throttling Implemented

Password reset and password change endpoints are rate limited per client to blunt automated guessing.

routes/auth.php, routes/settings.php โ€” throttle:6,1

ACCESS

Authorisation & Access Control

How the platform decides what an authenticated person is allowed to reach.

ACCESS-01 Role-gated administrative routes Implemented

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

ACCESS-02 Least-privilege delegation Implemented

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

Data Handling

How records are written, queried, and kept out of responses that should not carry them.

DATA-01 Mass-assignment allow-lists Implemented

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

DATA-02 Credential redaction in responses Implemented

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-03 Parameterised queries Implemented

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

DATA-04 Cookie payload encryption Implemented

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

APP

Application Hardening

Protections against requests and content that arrive looking legitimate.

APP-01 Cross-site request forgery Implemented

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

APP-02 Server-side HTML sanitisation Implemented

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

File Upload Handling

How documents, manuscripts and images submitted to the platform are accepted and stored.

FILE-01 Type allow-listing Implemented

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

FILE-02 Size limits Implemented

Each upload endpoint enforces a maximum file size appropriate to what it accepts, bounding resource consumption per request.

max: rules across App\Http\Requests

FILE-03 Server-generated filenames Implemented

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

PAY

Payment Data

What the platform does and does not hold in connection with conference fees.

PAY-01 No cardholder data Implemented

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

PAY-02 Local receipt processing Implemented

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

PRIV

Privacy Controls

The control a person retains over their own record.

PRIV-01 Self-service account deletion Implemented

Account deletion is available from profile settings, is confirmed with the account password, and invalidates the session on completion.

Settings\ProfileController::destroy

PRIV-02 Unauthenticated unsubscribe Implemented

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

Questions about this report? Email hello@scholarmeet.com.