Kryptobørs API-sikkerhet begynner med et enkelt prinsipp: en nøkkel skal bare kunne gjøre det boten trenger. En bot som leser priser og legger inn ordre trenger normalt ikke uttaksrettighet. En hemmelighet i et offentlig kodearkiv, én nøkkel for alle systemer eller ubegrensede ordre kan gjøre en liten konfigurasjonsfeil til et stort tap. Norske brukere bør også kontrollere identitetskrav, eurobetaling, produktets tilgjengelighet i EØS og hvordan transaksjonsdata oppbevares. Automatisering gir fart, men fjerner ikke markeds- eller driftsrisiko.

Lag en egen nøkkel

Opprett separate API-nøkler for hver bot, testmiljø og produksjonsmiljø. Ikke bruk hovedpassordet eller samme nøkkel i flere programmer. Registrer formål, opprettelsesdato og dato for neste gjennomgang i en intern oversikt, uten å lagre selve hemmeligheten der. Deaktiver nøkler som ikke lenger brukes. Separate nøkler gjør det lettere å finne hvilket system som sendte en ordre. Test- og produksjonsnøkler bør ha ulike beløpsgrenser. Ikke kopier secret til chat, skjermbilder, feilrapporter eller filer som alle serverbrukere kan lese.

Gi bare nødvendige rettigheter

Børser skiller ofte mellom lesetilgang, trading og uttak. Test først bare med lesetilgang. Aktiver trading etter at koden er kontrollert. La uttak være avslått når boten ikke trenger det. Undersøk om nøkkelen kan endre sikkerhetsinnstillinger, administrere andre brukere eller hente data som ikke trengs. Noter hvem som endret rettighetene og hvorfor. En bred tillatelse er praktisk, men en stjålet nøkkel får da større skadeomfang. Minste privilegium bør være standard, ikke et ekstra sikkerhetstiltak som kanskje kommer senere.

Bruk IP-allowlist

Hvis børsen støtter IP-allowlist, tillat bare serveren du kontrollerer. Unngå å åpne for alle adresser for å løse en midlertidig tilkoblingsfeil. En dynamisk hjemmeadresse kan gi avbrudd, så en kontrollert server med dokumentert nettverk er ofte bedre for en bot. Følg børsens offisielle prosedyre hvis leverandøren endrer IP. Flere miljøer trenger egne nøkler og egne lister. Et stort IP-område reduserer verdien av begrensningen og gjør en lekket secret enklere å misbruke.

Oppbevar hemmeligheter sikkert

API key, secret og autorisasjonsdata skal ikke ligge i kildekode, offentlige repoer, vanlige logger eller meldinger. Bruk en secret store eller en konfigurasjon med begrensede leserettigheter. Masker nøkkelverdier i logger og sørg for at sikkerhetskopier er kryptert. Hvis du mistenker lekkasje, deaktiver nøkkelen med en gang, avslutt ukjente økter og kontroller ordreloggen. Ikke vent til boten lager neste ordre. Support skal aldri be om passord, 2FA-kode, API-secret eller gjenopprettingsfrase. Bruk bare den offisielle supportsiden.

Sett grenser for ordre og tap

En trygg bot trenger maksverdi per ordre, maks antall åpne posisjoner, tillatte symboler, prisavvik og daglig tapsgrense. Avvis et signal hvis det er gammelt eller prisen har beveget seg lenger enn regelen tillater. Legg til en tidsgrense for åpne posisjoner og et tydelig stop-nivå. I produkter med gearing må risikoen beregnes ut fra kontraktens nominelle størrelse, ikke bare marginen. Likvidasjon er ikke en god erstatning for stop. Test grenser med et lite beløp før du bruker reelle midler.

Rate limit og gjentakelser

API-et har grenser for hvor mange forespørsler som kan sendes. En bot som gjentar alt uendelig kan lage doble ordre eller bli blokkert. Bruk økende ventetid, unik client order ID og idempotent behandling. En nettverksfeil betyr ikke nødvendigvis at ordren ble avvist; sjekk ordreloggen før du prøver på nytt. Lagre tidspunkt, responskode og order ID, men masker hemmeligheter. Feil må klassifiseres slik at boten skiller en ny ordre fra en gjentatt forespørsel. Hastighet er mindre viktig enn forutsigbar utførelse.

Logger, varsler og nødstopp

Logg signaltid, par, retning, ordretype, størrelse, pris, faktisk utførelse, gebyr, slippage og avvisningsgrunn. Varsle ved ny innlogging, uvanlig stor ordre, mange feil, raskt tap eller API-problemer. Legg aldri secret i varselet. Sammenlign botens logg med børsens trade history hver uke. Et kill switch skal kunne stoppe nye ordre eller deaktivere nøkkelen og må testes før en hendelse. Bestem på forhånd hva som skjer med åpne posisjoner. Start ikke boten igjen før årsaken til hendelsen er forstått.

Norske og europeiske forhold

Produkter, KYC, betalingsmetoder og grenser kan variere etter bosted. Les børsens aktuelle vilkår og kontroller at funksjonen er tilgjengelig for en norsk kunde. Registrer kostnader for euroinnskudd, vekslingskurs, handel, funding og uttak. Oppbevar handelshistorikk, gebyrer og overføringer på en sikker måte. Kryptoeiendeler er volatile, og skatte- og regelverkskrav kan endres. Ikke anta at erfaring fra en annen plattform gjelder her. Ved usikkerhet bør du innhente kvalifisert rådgivning og la boten stå av til reglene er forstått.

Før boten startes

  • Har nøkkelen bare nødvendige lese- og tradingrettigheter?
  • Er uttak og endring av sikkerhet deaktivert?
  • Er IP-liste og lagring av secret kontrollert?
  • Finnes grenser for størrelse, symbol, pris og daglig tap?
  • Unngår retry-logikken doble ordre?
  • Fungerer logger, varsler og kill switch i test?

Kryptobørs API-sikkerhet er en løpende prosess. Gjennomgå nøkler, rettigheter, grenser og logger etter endringer i kode, server eller børsens vilkår. Automatisering garanterer ikke gevinst og fjerner ikke markedsrisiko. Bruk offisiell API-dokumentasjon og start med liten størrelse. Denne artikkelen er pedagogisk og er ikke investeringsråd eller en garanti mot tap.

Flere guider fra CryptoSigy

CryptoSigy dekker også likviditet, gebyrer, funding og risiko ved signalutførelse. Les CryptoSigy-bloggen på norsk og gjenta sikkerhetskontrollen etter hver konfigurasjonsendring.