Datoteka .htaccess je niz praktičnih varnostnih metod, ki se uporablja za zaščito imenikov z uporabniškim imenom in geslom na strežnikih, ki temeljijo na Apache ali LiteSpeed. Z njeno pomočjo lahko preprečimo zunanji dostop do .htaccess datoteke, uvedemo obveznost HTTPS ter omejimo škodljive dostope. Najpogostejša uporaba je zaščita dostopa do imenika prek Basic Auth in shranjevanje gesel v datoteki .htpasswd. Pomembno pa je vedeti, da Basic Auth sam po sebi ne šifrira podatkov; za varno uporabo mora delovati preko SSL certifikata in HTTPS. SSL certifikat varna spletna gostovanja
Varnost spletnih strani je pogosto povezana z obsežnimi požarnimi zidovi, zapletenimi programi ali dragimi vtičniki. Vendar pa lahko pravilno konfigurirana datoteka .htaccess služi kot prva obrambna linija, zlasti pri deljenih gostovanjih, WordPressu, prilagojenih PHP aplikacijah in spletnih straneh manjših podjetij. S to datoteko lahko zaščitite kritične mape, kot je upravljalska plošča, preusmerite HTTP promet na HTTPS, onemogočite pregledovanje imenikov, omejite dostop do določenih datotek, zmanjšate uporabo hotlinking in aktivirate osnovne varnostne glave.
V tem priročniku bomo korak za korakom obravnavali postopek šifriranja datoteke .htaccess, razložili najbolj pogosto uporabljene varnostne ukaze v praksi in delili primere, ki jih lahko kopirate in prilagodite. Ukazi v vsebini so primerni predvsem za gostiteljske okolje, ki podpirajo Apache mod_rewrite, mod_auth_basic in mod_headers. Ker so strežniki LiteSpeed tudi v veliki meri združljivi z Apache, večina pravil deluje na enak način. Pred uporabo na živi spletni strani pa je priporočljivo, da najprej naredite varnostno kopijo datoteke in, če je mogoče, izvedete teste na poddomeni. upravljanje domen varnostno kopiranje spletne strani
Kaj je .htaccess datoteka in zakaj je pomembna za varnost?
.htaccess je lokalna konfiguracijska datoteka, ki določa, kako se strežnik obnaša za določen imenik in podimenike. Ko je postavljena v glavni imenik, ponavadi vpliva na celotno spletno stran; na primer, datoteka .htaccess v mapi public_html upravlja pravila, ki delujejo v glavni spletni mapi vašega domenskega imena. Ko je postavljena v podimenik, pa je veljavna samo za ta imenik in poti pod njim.
S to datoteko lahko izvajamo nadzor dostopa na ravni strežnika, kar pomeni, da lahko določene zahteve blokiramo, preden dosežejo kodo aplikacije. Na primer, če zaščitite admin imenik z geslom, se napadalec zlahka ne more dostopati do vaše WordPress, prilagojene plošče ali PHP datoteke, preden se ne uspe preveriti s strežnikom. Ta pristop zmanjšuje poskuse brute force in otežuje izkoriščanje morebitnih ranljivosti na ravni aplikacije.
Prednosti datoteke .htaccess z vidika varnosti so:
- Definiranje pravil za dostop brez spreminjanja kode aplikacije.
- Zaščita določenih imenikov z uporabniškim imenom in geslom.
- Samodejno preusmerjanje HTTP zahtevkov na HTTPS.
- Omejevanje pregledovanja imenikov, dostopa do občutljivih datotek in uporabe hotlinking.
- Z varnostnimi glavami lahko izboljšate obnašanje brskalnika.
- Omejevanje dostopa na podlagi IP naslova, datotečnih končnic ali metod zahtev.
Vendar pa .htaccess ne zagotavlja celotne varnosti sam. Najboljši rezultati se dosežejo v kombinaciji z aktualno programsko opremo, močno politiko gesel, rednim varnostnim kopiranjem, zanesljivo gostiteljsko infrastrukturo, WAF, skeniranjem zlonamerne programske opreme in SSL certifikatom. varnost gostovanja varnost WordPress
Logika šifriranja .htaccess: Basic Auth in .htpasswd
Izraz šifriranje datoteke .htaccess običajno pomeni dve različni stvari. Prva je zahteva po uporabniškem imenu in geslu ob vstopu v imenik; druga pa preprečitev, da bi bila sama datoteka .htaccess vidna od zunaj. Prvi postopek se izvede z Basic Auth, drugi pa z pravili za omejevanje dostopa do datotek.
V strukturi Basic Auth datoteka .htaccess vsebuje pravilo za preverjanje pristnosti, datoteka .htpasswd pa shrani uporabniška imena in šifrirane gesle. Gesla ne smejo biti shranjena v navadnem besedilu. V sodobnih sistemih se uporabljajo metode hash, kot so bcrypt, Apache MD5 ali SHA. Najbolj varna možnost je uporaba nastavitev za zaščito imenikov ali funkcije zaščitenega imenika v nadzorni plošči vašega gostovanja; ker te plošče običajno pravilno postavijo datoteko .htpasswd in samodejno opravijo postopek hashanja gesla.
Primer pravila za zaščito gesla je naslednji:
AuthType Basic
AuthName Zaščiteno Območje
AuthUserFile /home/uporabnik/.htpasswd
Require valid-user
Pomen teh štirih vrstic je preprost: vrsta preverjanja pristnosti je nastavljena na Basic, ime domena, ki se prikaže v brskalniku, je določeno, prikazana je popolna pot do datoteke .htpasswd, kjer so shranjena gesla uporabnikov, in dostop je dovoljen samo veljavnim uporabnikom. Najpogostejša napaka je, da se pot do AuthUserFile vnese kot URL. Pravilna vrednost ni spletni naslov, temveč fizična pot do datoteke na strežniku. Na primer, https://siteime.com/.htpasswd je napačno; /home/uporabnik/.htpasswd je blizu pravilni obliki.
Kje naj bo shranjena datoteka .htpasswd?
Datoteko .htpasswd je najbolje shraniti izven mape public_html. Tako tudi v primeru napačne konfiguracije strežnika datoteka ne more biti dostopna prek spleta. Na primer, če vaše spletno mesto deluje v /home/uporabnik/public_html, je bolj varno postaviti datoteko .htpasswd v /home/uporabnik/.htpasswd, ki je zunaj korena spletnega mesta.
Kar zadeva dovoljenja datoteke, je praktična začetna vrednost za .htpasswd 640 ali 644, za .htaccess pa 644. Odvisno od konfiguracije strežnika so morda potrebna drugačna dovoljenja; vendar pa dovoljenja, kot je 777, ki omogočajo pisanje vsem, predstavljajo varnostno tveganje in jih ne smemo uporabljati.
Korak za korakom šifriranje imenika z .htaccess
Naslednji koraki so primerni predvsem za uporabnike, ki želijo zaščititi imenike, kot so admin, plošča, test, staging, poročila ali datoteke po meri za stranke. Preden začnete, naredite varnostno kopijo obstoječe datoteke .htaccess. Tudi en napačen znak lahko povzroči napako 500 Internal Server Error.
1. Določite imenik, ki ga želite zaščititi
Najprej razjasnite, kateri imenik želite šifrirati. Na primer, če želite zaščititi samo področje siteime.com/admin, lahko datoteko .htaccess postavite v imenik admin. Če želite začasno zapreti celotno spletno stran in jo odpreti le pooblaščenim osebam, lahko pravilo dodate v datoteko .htaccess v glavnem imeniku.
2. Ustvarite uporabnika .htpasswd
Najbolj praktična metoda je, če imate v nadzorni plošči gostovanja orodje za zaščito imenika z geslom. Če orodja ni, lahko na strežnikih z dostopom do SSH ustvarite uporabnika z ukazom htpasswd. Osnovna logika je naslednja: htpasswd -c /home/uporabnik/.htpasswd admin. Ta ukaz ustvari geslo za uporabnika admin in ga shrani v datoteko. Pri dodajanju novega uporabnika obstoječi datoteki ne uporabljajte parametra -c; sicer bo datoteka ponovno ustvarjena.
3. Dodajte pravilo .htaccess
V datoteko .htaccess v zaščitenem imeniku dodajte naslednje vrstice:
AuthType Basic
AuthName Upravljanje Plošča
AuthUserFile /home/uporabnik/.htpasswd
Require valid-user
Ko shranite, odprite ustrezen imenik v brskalniku. Če se prikaže zaslon za uporabniško ime in geslo, je postopek uspešen. Čeprav je geslo pravilno, morda dostop ni mogoč, ker je pot do AuthUserFile napačna ali pa strežnik ne more prebrati dovoljenj datoteke .htpasswd.
4. Nikoli ne uporabljajte brez HTTPS
Basic Auth prenaša podatke o identiteti v Base64; to ni resna zaščita. Če promet poteka prek HTTP, lahko nekdo, ki prestreza omrežje, ujame uporabniško ime in geslo. Zato je pravilo šifriranja datoteke .htaccess vedno treba izvajati skupaj z obvezno uporabo HTTPS. Na Hostragons lahko to tveganje zmanjšate tako, da aktivirate SSL in nato dodate pravilo za preusmeritev HTTPS. namestitev SSL preusmeritev HTTPS
Obveznost HTTPS in preusmeritev www
Eden izmed osnovnih korakov za povečanje varnosti spletne strani je preusmeritev vsega prometa na HTTPS. Ko je SSL certifikat aktiven, lahko v datoteko .htaccess v glavni mapi dodate pravilo v naslednji logiki:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
To pravilo prenese zahteve, ki prihajajo preko HTTP, na HTTPS, pri čemer ohranja isto domeno in pot. Trajna preusmeritev, ki pomeni 301, daje tudi pravilne signale za SEO. Vendar pa, če imate obratni proxy, CDN ali uravnoteževalnik obremenitve, lahko HTTPS stanje preberete iz različnih glav. V takih primerih je treba uporabiti preusmeritvena pravila, ki jih priporoča vaš ponudnik gostovanja.
Izbira med domeno www in brez www mora biti dosledna. Na primer, če želite preusmeriti ves promet na različico brez www, lahko uporabite naslednji pristop:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.primerdomena\.com$ [NC]
RewriteRule ^(.*)$ https://primerdomena.com/$1 [L,R=301]
Tukaj morate zamenjati ornekdomain.com s svojo domeno. Če hkrati izvajate tako preusmeritev HTTPS kot www, pazite, da ne ustvarite verižnih preusmeritev. Idealna struktura uporabnika pripelje do končnega URL-ja v enem koraku. preusmeritev domene SEO prijazne preusmeritve
Osnovni ukazi za povečanje varnosti spletne strani z .htaccess
Spodnja tabela povzema najpogosteje uporabljene varnostne ukaze .htaccess in kdaj jih uporabiti. Pred dodajanjem vsakega ukaza preverite obstoječo konfiguracijo; lahko pride do konflikta s pravili WordPress, Laravel ali drugih prilagojenih CMS-jev.
| Cilj | Primer ukaza ali direktive | Kdaj uporabiti? | Na kaj je treba paziti |
|---|---|---|---|
| Šifriranje imenika | AuthType Basic, Require valid-user | Imeniki za admin, staging, poročila | Zagotovo mora biti uporabljeno skupaj z HTTPS |
| Obveznost HTTPS | RewriteCond %{HTTPS} off | Za vse prometne tokove na spletni strani | Če je prisoten CDN, so morda potrebna posebna pravila |
| Onemogočanje pregledovanja imenikov | Options -Indexes | V imenikih brez praznega index datoteka | Preprečuje prikaz strukture datotek |
| Zaščita .htaccess | Require all denied | Preprečuje branje konfiguracijskih datotek | Sintaksa se lahko razlikuje glede na različico Apache |
| Omejevanje hotlinking | RewriteCond %{HTTP_REFERER} | Zmanjšanje uporabe slik na drugih straneh | Preverite delovanje CDN in predogledov na družbenih omrežjih |
| Varnostne glave | Header set X-Frame-Options SAMEORIGIN | Zmanjšanje napadov na ravni brskalnika | mod_headers mora biti aktiven |
Onemogočanje pregledovanja imenikov
Če v imeniku ni index.html, index.php ali privzete vhodne datoteke, lahko strežnik prikaže seznam datotek. To predstavlja tveganje za varnost, saj lahko vključuje varnostne kopije, slike, začasna poročila ali stare izvorne kode. S preprostim ukazom lahko onemogočite pregledovanje imenikov:
Options -Indexes
Po tem ukazu uporabniki ne morejo več pregledovati vsebine imenika. Običajno se pri imenikih brez index datoteke prikaže napaka 403 Forbidden. To obnašanje je zaželeno z vidika varnosti.
Onemogočanje dostopa do občutljivih datotek z .htaccess
Vaša datoteka .htaccess ne sme biti vidna prek spleta. Apache to datoteko običajno privzeto ščiti; vendar pa lahko kot dodatno plast zaščite uporabite naslednjo logiko:
<Files .htaccess>
Require all denied
</Files>
Podobno morajo biti dostopi do datotek, kot so .env, composer.json, composer.lock, config.php.bak, backup.sql, database.sql, prav tako onemogočeni. Zlasti Laravel, Symfony ali prilagojene PHP aplikacije lahko vsebujejo občutljive informacije, kot so gesla za bazo podatkov, API ključi in SMTP podatki. Izpostavljenost teh datotek lahko vodi do prevzema celotnega sistema.
Za blokiranje več različic občutljivih datotek uporabite naslednjo logiko:
<FilesMatch ^(\.env|composer\.(json|lock)|package\.json|yarn\.lock|.*\.sql|.*\.bak)$>
Require all denied
</FilesMatch>
Pri dodajanju takih pravil se prepričajte, da ne blokirate statičnih datotek, ki jih vaša aplikacija dejansko potrebuje. Na primer, če bi bile vključene nekatere datoteke za preverjanje ali integracijo, bi lahko to povzročilo težave s delovanjem tretjih oseb.
Onemogočanje izvajanja PHP v določenih imenikih
Imeniki za nalaganje so eno izmed najbolj tarčenih področij za napadalce. Če je sistem s slabo kontrolo nalaganja datotek, lahko nalaganje zlonamerne PHP datoteke predstavlja veliko tveganje. Onemogočanje izvajanja PHP v imenikih, kjer se nalagajo slike ali mediji, zagotavlja dodatno zaščito.
V datoteko .htaccess v ustreznem imeniku lahko dodate naslednjo logiko:
<FilesMatch \.php$>
Require all denied
</FilesMatch>
Tako pravilo onemogoča dostop do PHP datotek v ustreznem imeniku. Pri WordPressu je podoben pristop pogosto uporabljen v wp-content/uploads, vendar je treba to preizkusiti, saj nekatere vtičnike morda potrebujejo posebne obdelave datotek.
Onemogočanje hotlinking za zmanjšanje porabe prometa
Hotlinking pomeni, da druge strani neposredno uporabljajo vaše slikovne datoteke na svojih straneh. To povečuje porabo pasovne širine in lahko povzroči težave s delovanjem. Preprosto pravilo za onemogočanje hotlinkinga je naslednje:
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?primerdomena\.com [NC]
RewriteRule \.(jpg|jpeg|png|gif|webp)$ - [F,NC]
To pravilo blokira zahteve za slike, ki prihajajo z neobstoječim refererjem in ne iz vaše domene. Vendar pa, če imate Google Images, predogledov družbenih omrežij, CDN domen ali partnerjev, boste morda morali te domene dodati na belo listo. uporaba CDN zmogljivost spletne strani
Dovoljevanje ali blokiranje določenih IP naslovov
Če želite dostopati do nadzorne plošče samo iz pisarniškega IP naslova, je omejitev IP učinkovita dodatna plast zaščite. Za Apache 2.4 in novejše je osnovna logika:
Require ip 203.0.113.10
To pravilo samo dovoljuje dostop določenemu IP naslovu. Če uporabljate dinamični IP, bodite previdni; če se vaš IP spremeni, morda ne boste mogli dostopati do svoje nadzorne plošče. Za bolj prilagodljivo uporabo je morda bolje, da omejitev IP izvajate skupaj z zaščito z geslom.
Za blokiranje določenega zlonamernega IP naslova lahko uporabite naslednjo logiko:
<RequireAll>
Require all granted
Require not ip 198.51.100.25
</RequireAll>
Blokiranje IP naslovov deluje pri manjših napadih; vendar ni dovolj, če gre za botnet ali napade z dinamičnimi IP naslovi. V takih primerih so rešitve za varnostne požarne zidove aplikacij, omejevanje hitrosti in varnostna rešitev na strani strežnika bolj učinkovite.
Varnostne glave: Dodatna zaščita na ravni brskalnika
.htaccess se lahko uporablja ne le za nadzor dostopa, temveč tudi za upravljanje varnostnih glav na ravni brskalnika. Če je mod_headers aktiven, spodnje glave povečujejo osnovno raven varnosti na mnogih straneh:
Header always set X-Content-Type-Options nosniff
Header always set X-Frame-Options SAMEORIGIN
Header always set Referrer-Policy strict-origin-when-cross-origin
Header always set Permissions-Policy geolocation=(), microphone=(), camera=()
X-Content-Type-Options nosniff zmanjša možnost, da bi brskalnik ugibal vrste datotek in jih izvajal. X-Frame-Options SAMEORIGIN omejuje vgrajevanje vaše strani v iframe na drugih domenah in zmanjšuje tveganje za clickjacking. Referrer-Policy nadzira, katere informacije o refererju se bodo delile med preusmeritvijo. Permissions-Policy omejuje dostop do brskalniških dovoljenj, kot so kamera, mikrofon in lokacija.
Content-Security-Policy, znan tudi kot CSP, je močnejša varnostna glava, vendar jo je treba skrbno izvajati. Preveč stroga CSP lahko ovira delovanje oglasov, analitik, plačil, podpore v živo ali storitev pisav. Zato je najbolje, da najprej testirate v režimu poročanja in nato postopoma uvedete v živo.
Kontrolni seznam pred izvajanjem

Spremembe v datoteki .htaccess delujejo hitro. Zato je priporočljivo, da pred dodajanjem varnostnih ukazov sledite kratkemu kontrolnemu seznamu, da zmanjšate tveganje za prekinitev delovanja.
- Prenesite varnostno kopijo obstoječe datoteke .htaccess na svoj računalnik.
- Preverite, ali je vaš SSL certifikat aktiven in pravilno nameščen.
- Dodajte preusmeritvena pravila eno za drugo; ne spreminjajte vseh pravil hkrati.
- Preverite napake 500, 403 in 404 v brskalniku in strežniških dnevnikih napak.
- Ne brišite svojih lastnih pravil za preusmeritev v WordPressu, Laravelu ali prilagojeni programski opremi.
- Preizkusite obveznost HTTPS na tistih področjih, kjer uporabljate zaščito z geslom.
- Če uporabljate CDN, vtičnike za predpomnjenje in varnostne vtičnike, preučite možnost konfliktov.
- Preizkusite prijave, obrazce in tokove plačil na mobilnih, namiznih in različnih brskalnikih.
Postopno uvajanje pravil je v praksi zelo pomembno. Na primer, najprej dodajte Options -Indexes in preizkusite, nato dodajte preusmeritev HTTPS in na koncu preidite na zaščito z geslom. Tako boste lahko hitro našli vrstico, ki je povzročila težavo, v primeru, da se pojavijo težave.
Najpogostejše napake in načini reševanja
500 Internal Server Error
Ta napaka običajno izhaja iz napake v sintaksi, nepodprte direktive ali napačne uporabe modula. Na primer, uporaba ukaza Header, ko mod_headers ni aktiven, lahko povzroči napako. Za rešitev začasno odstranite zadnje dodane vrstice, preglejte dnevnike napak strežnika in preverite, ali vaš gostiteljski okolje podpira ustrezen modul.
Zaslon za geslo se nenehno ponavlja
Čeprav sta uporabniško ime in geslo pravilna, se zaslon nenehno ponavlja, lahko pomeni, da je pot do .htpasswd napačna, format hasha gesla ni podprt s strežnikom ali pa so dovoljenja datoteke napačna. Prepričajte se, da uporabljate popolno fizično pot v vrstici AuthUserFile.
Preusmeritev HTTPS povzroča neskončno zanko
Na straneh za CDN ali proxy strežnik lahko zahtevo vidi kot HTTP in nenehno poskuša preusmeriti na HTTPS. V takem primeru je morda potrebna posebna pravila, ki upošteva naslove, kot je X-Forwarded-Proto. Pomembno je tudi, da je modul SSL na nadzorni plošči CDN nastavljen na ustrezen nivo, kot je Full ali Full Strict.
Slike ali CSS datoteke se ne odpirajo
Če so pravila za hotlink, FilesMatch ali varnostne glave preširoka, lahko to povzroči blokiranje legitimnih statičnih datotek. S pomočjo orodij za razvijalce v brskalniku lahko preverite, katera datoteka je bila blokirana s katero kodo HTTP.
Varnost .htaccess v WordPress straneh
Datoteka .htaccess je ključnega pomena za trajne povezave na WordPress straneh. Zato je pomembno, da pravil ne spreminjate brez potrebe, med blokoma BEGIN WordPress in END WordPress. Varnostna pravila je običajno bolje dodati nad ali pod te bloke.
Praktične varnostne ukrepe za WordPress vključujejo:
- Dodajanje zaščite Basic Auth v wp-admin imenik.
- Onemogočanje izvajanja PHP v wp-content/uploads.
- Omejitev dostopa do xmlrpc.php, če ga ne uporabljate.
- Zmanjšanje vidnosti datotek readme.html in licenčnih datotek.
- Usmerjanje HTTPS v skladu z naslovi spletne strani WordPress.
Posebej za wp-admin je uporaba tako gesla WordPress kot zaščite z geslom .htaccess učinkovita obramba. Vendar pa nekatere vtičnike, ki uporabljajo AJAX, potrebujejo dostop do wp-admin/admin-ajax.php, zato je treba testirati delovanje po uporabi zaščite. WordPress gostovanje pospešitev WordPress
Strokovni nasveti za varnost .htaccess
Izkušeni sistemski skrbniki običajno najprej upoštevajo ravnotežje med varnostjo in vzdržljivostjo. Zelo agresivna pravila se lahko na kratki rok zdijo varna, a dolgoročno povečajo stroške vzdrževanja. Zato je treba zabeležiti namen, obseg in rezultate testiranja vsakega pravila.
- Pred kritičnimi spremembami naredite datoteko z datumom: htaccess-2026-01-15.bak.
- Izogibajte se dodajanju nepotrebnih stotin pravil v eno samo datoteko .htaccess.
- Ker so 301 preusmeritve trajne, upoštevajte predpomnilnike brskalnika in iskalnikov.
- Po dodajanju varnostnih glav preverite napake v konzoli brskalnika.
- Namesto deljenja šibkih gesel v zaščitenih imenikih ustvarite uporabnike na osnovi posameznikov.
- Preden iskalniki dostopajo do strežniških nivojev, zaprite testne, staging in varnostne imenike.
Pomembno je tudi redno pregledovanje varnostnih pravil. Integracija, ki se danes uporablja, je lahko jutri odstranjena; vendar pa lahko pot, ki je bila odprta zanj, ostane pozabljena v .htaccess. Kratki varnostni pregledi vsakih tri mesece so dobra navada za čiščenje nepotrebnih dovoljenj in posodabljanje starih preusmeritev.
Zaključek: Majhna datoteka, velika plast varnosti
Ukazi za šifriranje datoteke .htaccess in povečanje varnosti spletne strani okrepijo prvo obrambno linijo vašega spletnega mesta proti napadom, če se pravilno uporabljajo. Zaščita imenikov z geslom, uvedba obveznega HTTPS, onemogočanje pregledovanja imenikov, omejevanje dostopa do občutljivih datotek in aktiviranje varnostnih glav so izvedljivi, merljivi in učinkoviti koraki za večino spletnih mest.
Vendar pa varnost .htaccess sama po sebi ni dovolj. Potrebno je razmišljati o zanesljivi gostiteljski infrastrukturi, aktualni programski opremi, SSL certifikatu, rednem varnostnem kopiranju in močni politiki gesel. Na Hostragons lahko upravljate osnovne varnostne komponente, kot so SSL, gostovanje in upravljanje domen iz enotne nadzorne plošče ter postopoma napredujete proti varnejši strukturi, ko jo potrebujete. paketi spletnega gostovanja nakup domene SSL certifikati
Pogosto zastavljena vprašanja
Ali .htaccess datoteka res šifrira datoteke?
Ne. Ta izraz se običajno uporablja za zaščito imenikov z uporabniškim imenom in geslom. Dostop do Basic Auth je omejen; za varno prenašanje podatkov je treba uporabljati SSL in HTTPS.
Ali je varno hraniti datoteko .htpasswd znotraj public_html?
Ni priporočljivo. Najbolj varna možnost je, da datoteko .htpasswd hranite izven public_html, v imeniku, ki ni dostopen prek spleta. Tako se zmanjša verjetnost, da bi bila datoteka izpostavljena tudi v primeru napačne konfiguracije.
Kaj naj storim, če po spremembi .htaccess dobim napako 500?
Najprej odstranite zadnje dodane vrstice ali se vrnite na varnostno kopijo. Nato preverite strežniške dnevniške napake. Napaka običajno izhaja iz tipkarske napake, nepodprte direktive ali neaktivnega Apache modula.
Ali je pravilno šifrirati wp-admin imenik z .htaccess?
Da, lahko zagotovi dodatno plast varnosti. Vendar pa nekatere vtičnike potrebujejo dostop do datotek, kot je admin-ajax.php, zato je nujno, da po uvedbi zaščite testirate dostop do funkcij, kot so prijave, komentarji, nakupi, plačila in obrazci.
Ali je preusmeritev HTTPS škodljiva za SEO?
Pravilno izvedena 301 preusmeritev HTTPS ni škodljiva; nasprotno, zagotavlja varno in dosledno strukturo URL. Ključno je, da ne ustvarite verižnih preusmeritev in da vse notranje povezave uskladite z končnimi HTTPS naslovi.