Sikkerhet
Hvordan rapportere en sårbarhet, hva vi lover til gjengjeld, og hvordan tjenesten er sikret.
Last updated: 2026-09-03
1. Å rapportere en sårbarhet
Send e-post til security@aukimi.com. Denne adressen er også publisert i https://aukimi.com/.well-known/security.txt. Vennligst rapporter privat først, og gi oss en sjanse til å utbedre problemet før du offentliggjør det.
2. Hva du bør inkludere
- Hva du fant, og hvorfor det er viktig — konsekvensen, ikke bare teknikken.
- Nøyaktige trinn for å gjenskape det, med URL-en, kontoen som ble brukt, og tidspunktet.
- Et konseptbevis begrenset til det som demonstrerer problemet.
- Hvordan du ønsker å bli kreditert, hvis du ønsker det.
3. Omfang
Omfattet: aukimi.com, app.aukimi.com, academy.aukimi.com, flerspiller-vertene under mp.aukimi.com, og det offentlige API-et.
- Ikke omfattet: tredjepartstjenester vi bruker, men ikke driver — rapporter disse til deres egne programmer.
- Ikke omfattet: funn fra automatiserte skannere uten dokumentert konsekvens, manglende sikkerhetsheadere alene, eller rapporter om at en hastighetsbegrensning finnes.
- Ikke omfattet: sosial manipulering av teamet vårt eller våre brukere, fysiske angrep, og alt som forringer tjenesten for andre.
4. Regler for engasjement, og trygg havn
Hvis du følger disse reglene mens du undersøker i god tro, vil vi behandle arbeidet ditt som godkjent, vi vil ikke forfølge deg, og vi vil ikke be noen andre om å:
- Bruk kun dine egne kontoer og dine egne data. Stopp ved første tegn på at du kan nå noen andres.
- Ikke ekstraher, endre eller ødelegg data — et skjermbilde som beviser tilgang, er nok.
- Ingen tjenestenektangrep, ingen belastningstesting, ingen spam.
- Gi oss rimelig tid til å utbedre et problem før du publiserer, og koordiner tidspunktet med oss.
5. Hva vi gjør til gjengjeld
- Vi bekrefter mottak av en rapport innen 5 virkedager.
- Vi gir deg vår vurdering og en tidsplan for utbedring innen 10 virkedager.
- Vi holder deg informert til problemet er løst, og vi krediterer deg hvis du ønsker å bli kreditert.
Vi kjører for øyeblikket ikke en betalt feilbelønningsordning (bug bounty). Vi sier det rett ut i stedet for å la det være uklart.
6. Hvordan tjenesten er sikret
Hva som allerede er på plass, slik at en rapport kan rettes mot noe nytt fremfor det vi allerede vet:
- HTTPS overalt, HSTS, og en innholdssikkerhetspolicy (content security policy) som forbyr innebygde hendelseshåndterere.
- Passord hashes med bcrypt med 12 runder; økter er signerte JWT-er, låst til én enkelt algoritme.
- Hastighetsbegrensning på autentisering, på API-et, og separat på de uautentiserte endepunktene.
- Innlogging på tvers av domener bruker kortvarige autorisasjonskoder til engangsbruk fremfor tokens i URL-er.
- Opplastinger valideres på sine magiske bytes, strippes for EXIF, og serveres fra en sandkassebane; SVG avvises overalt der en fil kunne blitt et dokument.
- Betalte ressursfiler lagres utenfor det offentlige filtreet, slik at det er betaling som låser dem opp, ikke skjulthet.
7. Data- og personvernhendelser
Hvis en sårbarhet har eksponert personopplysninger, si fra om det i rapporten din — varslingsforpliktelsene som følger, er våre, og klokken starter når vi får kjennskap til det. Personvernerklæringen forklarer hvordan vi håndterer personopplysninger.