Skip to content

Governance

Integrity and security

A research organisation is trusted only if it refuses false prestige and locks the doors of its website.

Research integrity

  • No fabricated publications, citation counts, university partnerships, or world rankings are displayed.
  • Guest names appear only as the Facebook page named them, or with a home-institution biography clearly labelled as independent. Centre officer titles are those the organisation supplied; portraits appear only on named Centre graphics.
  • The journal follows COPE-aligned authorship, conflict-of-interest, and correction practice.
  • Human-subjects work will require an ethics statement before review proceeds.

Application security (this website)

  • Transport: the live site must be served only over HTTPS. Hostinger should force SSL.
  • Input: contact and manuscript fields are sanitised on the server, length-capped, and rejected if they look like script injection.
  • Bot trap: a hidden honeypot field. Automated fillers that complete it are discarded silently.
  • Rate limit: a small number of attempts per email in a ten-minute window.
  • Data minimisation: names and emails from forms are not written to a world-writable public database.
  • XSS: user text is not rendered as HTML. Output is React text nodes.
  • Dependencies: production builds ship without eval-based template injection.
  • Secrets: no API keys or database passwords are embedded in the browser bundle.
  • Cookies: this public site does not set tracking cookies.
  • Content: Facebook is linked, not scraped into an untrusted HTML embed, so the page cannot be used as an open redirect or script host.
  • Gallery writes are not public. A staff key is compared in constant time. JPEG/PNG/WebP files are accepted only after magic-byte checks, size limits, and a honeypot.
  • Facebook photographs are pulled only with an official Page access token on the server. The token never ships in the browser bundle. There is no delete-all control.
  • Graph API scopes used for the gallery are read-only: pages_show_list and pages_read_engagement. Publish, messaging, and ads permissions are not requested.
  • A Hostinger cron may call /api/gallery-cron with a separate secret. Failed or unauthorized calls return no files.
  • There is no public login or user-account panel. The only lock is the gallery desk staff key. Public visitors cannot write, upload, or change records.
  • Outbound fetches for gallery sync are limited to graph.facebook.com and Facebook photo CDNs over HTTPS, with redirects refused.
  • Served gallery bytes are re-checked for JPEG/PNG/WebP magic numbers so a poisoned record cannot be delivered as HTML.
  • Responses send nosniff, a strict referrer policy, a Permissions-Policy that turns off camera, microphone, geolocation, payment, USB, sensors, autoplay, fullscreen, clipboard, and related device APIs, and a Content-Security-Policy that allows only this origin’s scripts, Google Fonts, and same-origin images. Inline event handlers, plugins, and nested frames are blocked. The policy does not forbid the site from being previewed in a frame.
  • CSP and Permissions-Policy violations are POSTed to a same-origin inbox, rate-limited, size-capped, never executed, and visible only after the staff key. Browser-extension noise is tagged. An empty inbox is the healthy state.

What you should still do on Hostinger

  • Turn on Force HTTPS and enable the free SSL certificate.
  • Turn on hotlink protection and disable directory listing.
  • Keep PHP disabled if you only upload static files from this project’s build, or keep PHP updated if you use Hostinger’s mail endpoint later.
  • Create an application-specific mailbox (for example submissions@yourdomain) and never reuse a personal password.
  • Add a DNS CAA record and enable Hostinger’s WAF / ModSecurity if available.
  • Take weekly backups. Do not share cPanel passwords.
  • When you add email sending, use authenticated SMTP — never an open form-to-mail script.

Page administrators: Gallery desk