Static site security

Before talking about the possibility of hacking, it is necessary to evaluate the possible profit from this:

• Getting control of someone else’s computing power : it’s unrealistic, Github is protected even from you in this regard: it does not allow the use of custom plugins for Jekyll (the only supported engine) that can contain arbitrary Ruby code.

  Hold tight to your GitHub account:

  • Enable two-factor authentication.
  • For Git authentication, use SSH keys and assign such names to them so that you can find out which key should be denied access on occasion.

• Getting confidential user data : do you collect it? Store? Github Pages does not provide any server-side storage. There remains the option of storing data on the client (there is nothing there now: WebSQL, IndexedDB, LocalStorage) or interception right at the input.

  In the absence of access to the client at least at the browser level (if the user has malicious extensions in the browser or holes / loopholes in the OS, you are unlikely to do something) it remains only to deceive the user to execute the attacker's JS code: this is XSS .

  The most trivial case is the output of a fragment of the URL without escaping: if there is "accidentally" (via a link sent by someone) there is a <script> with malicious code, the browser will download and execute it. There are less obvious, this is a vast topic .

• Putting a site inoperable ...

  Lock burglary providers are probably not considered to be, although they make the site inoperative for a certain circle of users. We consider the inoperability for all (or almost all; of course, from the source, anyone can pick up a copy in themselves).

  The only vulnerability is the domain : it can theoretically be "hijacked" and sent to the attacker's car. If you use *.imtqy.com , then you rely on protecting your domain on GitHub. If you use your own, hold on tight to your account with the registrar.