ScholarMeet is Built on Trust
Conferences run on personal data — attendee records, unpublished manuscripts, payment receipts. This page sets out the protections that are actually implemented on the platform, so you can judge them rather than take our word for it.
Security Controls in Place
Each item below is enforced in the application itself — verified in code, not aspirational.
- Passwords are never stored in readable form Passwords are hashed with bcrypt before they are written, and the plaintext is never persisted or logged.
- Session IDs are regenerated on every login A new session identifier is issued on each successful sign-in — including Google sign-in — which prevents session-fixation attacks.
- Session cookies are HttpOnly and SameSite=Lax Session cookies cannot be read by JavaScript, and browsers will not send them on cross-site requests.
- CSRF protection is enabled site-wide Form submissions and other state-changing requests are verified against an anti-forgery token tied to your session, so another site cannot make those requests on your behalf.
- Cookies are encrypted Cookie payloads are encrypted and signed by default; only two non-sensitive UI preferences are exempt.
- Every database model uses an explicit field allow-list All models declare exactly which attributes may be set from request input, so a crafted form cannot write to a column it was never meant to touch.
- Role-based access control on administrative routes Admin, host and organization routes are gated by dedicated middleware. Delegated sub-administrators additionally hold per-module grants, so access can be scoped to only the sections a person needs.
- Uploads are validated and stored under system-generated names Every upload is checked against an allow-list of file types with an enforced size limit, and is written under a name the platform generates rather than the one supplied by the browser.
- Rich text is sanitised before it is stored Editorial content is passed through an HTML allow-list on the server, stripping scripts, event handlers and javascript: URLs regardless of what the browser submitted.
- Database queries use parameter binding Data access goes through the query builder, and hand-written SQL fragments pass user input as bound parameters rather than string concatenation.
- Sign-in codes are single-use and short-lived Email one-time codes are generated with a cryptographic random source, expire after 10 minutes, and are deleted the moment they are used or superseded.
- Password reset and change endpoints are rate limited Requests to the password reset and password change endpoints are capped per client to blunt automated guessing.
- Google sign-in validates the OAuth state parameter The OAuth callback verifies the anti-forgery state value tied to your session, so an attacker cannot complete a sign-in flow they started.
How We Handle Your Data
What we collect, what we deliberately do not, and the control you keep over it.
- We never handle payment card data ScholarMeet stores no card numbers, CVVs, expiry dates or cardholder names. No such column exists anywhere in the database, and no card-processing gateway is integrated into the platform.
- Payment receipts are read in your browser When a payment receipt is scanned to read its details, that processing runs locally in your browser — the image is not sent to a third-party OCR service.
- Credentials are hidden from every API response Password hashes, remember-me tokens and third-party provider identifiers are excluded from serialisation, so they cannot leak through an API response or a page payload.
- Newsletter unsubscribe is one click, no login required Every newsletter email carries a tokenised unsubscribe link that works without signing in and takes effect immediately. Per-city subscriptions can also be managed individually.
- You can delete your account yourself Account deletion is available from your profile settings, is confirmed with your password, and clears the associated session on completion.
- We do not sell your personal information Your data is shared only with the conference organisers you register with, the service providers needed to operate the platform, and where the law requires it.
Our Privacy Policy sets out in full what we collect and who we share it with, and our Terms & Conditions cover the rules of using the platform.
Accessibility
Measures currently built into the interface.
- Semantic landmarks on public content pages Blog, FAQ and knowledge-base pages are built with real header, nav, main and article elements, so a screen reader can jump between regions instead of reading the page top to bottom.
- Accessible component primitives Menus, dialogs, tabs, switches and comboboxes are built on Radix UI, which supplies keyboard navigation, focus trapping and ARIA wiring for those components as standard behaviour.
- Form errors are exposed programmatically Inputs that fail validation are marked invalid for assistive technology and paired with a visible message, so the failure is not signalled by colour alone.
- Visible keyboard focus Interactive elements in the design system carry a distinct focus ring when reached by keyboard, so the current position is always apparent.
- Declared page language Every page declares its language, which lets screen readers select the correct pronunciation rules.
- Layouts reflow instead of scrolling sideways Pages adapt down to small screens rather than requiring horizontal scrolling, which is also what makes them usable at high browser zoom.
We describe specific measures rather than claiming a formal conformance level such as WCAG 2.1 AA, because that is the outcome of an independent audit which we have not yet completed. If you hit a barrier using ScholarMeet, tell us at hello@scholarmeet.com and we will treat it as a defect.
Download Documentation
Share with your institution, reviewers, or compliance team. Opens in a new tab — use your browser's Print → Save as PDF.
Compliance Certificate
Platform compliance declaration covering the security and data-handling controls in place, verified against the application source code.
Security Assessment Report
Application security assessment covering authentication, authorisation, data handling, file uploads, payment data and privacy controls.
Both documents are internal assessments issued by ScholarMeet about its own platform. Neither is a third-party audit or certification.
Responsible Disclosure
If you discover a security vulnerability in ScholarMeet, please report it responsibly. Do not exploit it, and do not disclose it publicly before we have had a chance to address it.
Our Commitment
Acknowledged and credited
No legal action for good-faith research
ScholarMeet Trust Center · Last reviewed August 2026
Security & Compliance FAQ
Common questions about data protection, access controls, and compliance on ScholarMeet.
Where is my data stored?
Do you store my payment card details?
Who can see the paper or abstract I submit?
Is ScholarMeet GDPR compliant?
Can I delete my account, and what happens to my data?
How is my account protected?
What cookies does the platform set?
Do you sell or share my personal information?
Has ScholarMeet had an external security audit?
How do I report a security vulnerability?
Something not covered here? Get in touch — we answer institutional security questionnaires.