Please report security issues privately to umut@guden.tr. Do not open a public issue, pull request or discussion for anything security related.

Include what you need to make the problem understandable: the affected component, what an attacker can achieve, and a reproduction if you have one. A proof of concept is welcome but not required.

You will get an acknowledgement within 72 hours. This is a solo project, so please allow reasonable time for a fix before any public disclosure. Credit will be given unless you prefer otherwise.

In scope:

• The iOS and watchOS app in App/.
• The AWS CDK backend in backend/, covering Sign in with Apple, session handling and the leaderboard lambdas.
• The site in site/.

Out of scope:

• Anything requiring a jailbroken device or physical access to an unlocked phone.
• Denial of service through sheer request volume against a service that is not deployed.
• Reports generated by automated scanners with no demonstrated impact.

For anyone reviewing: IAM permissions are written per action rather than with the broad grant* helpers, there is no table-wide scan, appleSub is projected out of leaderboard responses, Apple token verification hardcodes RS256 rather than trusting the JWKS alg field, a missing bundle ID fails the cold start rather than allowing an audience bypass, and every write is keyed on the session's own subject rather than a client-supplied identifier.

Session tokens are stored as sha256(token), never in plaintext: the raw 256-bit token is returned to the client once at sign-in and is never persisted, so read access to the Sessions table yields nothing that can be replayed. A plain hash rather than a password KDF is deliberate, because the token is already full-entropy random and has no guessing space to defend. POST /auth/signout revokes a session server-side by deleting its row, so signing out makes the token inert immediately rather than leaving it valid for the rest of its 90 day TTL.