Mga security check sa website na hindi kailangang mag-hack

Passive security check para sa online store: pag-expire ng TLS certificate, HSTS, CSP, nosniff, cookie flag, mixed content, lumang jQuery, security.txt at DMARC.

Pangkat Editoryal ng FixReports12 minutong pagbasa

Marami kang masusuri sa security setup ng isang online store mula sa labas, sa pamamagitan lang ng pagbasa sa mga bagay na ipinapadala na ng site sa bawat bisita: ang TLS certificate nito, mga redirect, mga HTTP response header, mga cookie, ang mga script na nilo-load nito at ang mga pampublikong DNS record nito. Hindi nagpapadala ng attack traffic ang mga passive check na ito at hindi nangangailangan ng login, kaya hindi sila nagdudulot ng mas mabigat na load sa store kaysa sa isang karaniwang pagbisita. Nahuhuli nila ang mga puwang sa configuration gaya ng malapit nang mag-expire na certificate, kawalan ng HSTS, mga hindi secure na cookie, mixed content o bersiyon ng jQuery na may mga kilalang depekto. Hindi ito penetration test at hindi nito mapapatunayang secure ang isang store.

Mga pangunahing punto

  • Ang mga publicly trusted na TLS certificate na inisyu mula Marso 15, 2026 ay puwedeng maging valid nang hanggang 200 araw lang; bababa ito sa 100 araw sa Marso 2027 at sa 47 araw sa Marso 2029 (CA/Browser Forum (magbubukas sa bagong tab)).
  • Hindi pinapansin ng mga browser ang HSTS header kapag ipinadala ito sa plain HTTP (MDN (magbubukas sa bagong tab)).
  • Hindi gumagana ang CSP directive na frame-ancestors sa isang <meta> tag; kailangang response header ito (MDN (magbubukas sa bagong tab)).
  • Apektado ng dalawang XSS vulnerability ang mga bersiyon ng jQuery bago ang 3.5.0, at idinagdag ng CISA ang isa sa mga ito, ang CVE-2020-11023, sa Known Exploited Vulnerabilities catalog nito noong Enero 23, 2025 (NVD (magbubukas sa bagong tab)).
  • Dapat may Contact at Expires na field ang isang security.txt file at dapat itong nakalagay sa /.well-known/security.txt (RFC 9116 (magbubukas sa bagong tab)).

Ano ang itinuturing na passive security check?

Binabasa lang ng isang passive check ang ibinabalik ng site o ng DNS nito sa isang karaniwang request.

Ibig sabihin nito ay pag-load ng mga pampublikong page, pagbasa sa certificate at mga response header, paglilista ng mga cookie at script na itinatakda ng isang page, at pag-query sa mga pampublikong DNS record. Hindi nanghuhula ng password ang isang passive check, hindi nagpapadala ng injection payload, hindi sumusubok ng mga admin URL at hindi nag-i-scan ng mga port. Lahat ng nasa ibaba ay magagawa gamit ang browser, curl, openssl at dig.

Paano mo susuriin ang TLS certificate mo at ang pag-expire nito?

Direktang basahin ang mga petsa at pangalan sa certificate, at tiyaking automated ang renewal.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Tiyaking malayo pa sa hinaharap ang notAfter, na saklaw ng certificate ang example.com at www.example.com kung pareho mong ginagamit ang mga ito (inililista ng certificate viewer ng browser ang mga pangalan), at na walang ipinapakitang babala ang browser. Umiikli ang buhay ng mga certificate ayon sa CA/Browser Forum Baseline Requirements (section 6.3.2, version 2.3.1 hanggang Oktubre 2026), alinsunod sa Ballot SC-081v3 (magbubukas sa bagong tab), na inaprubahan noong Abril 11, 2025:

Kailan inisyu ang certificatePinakamahabang validity
Bago ang Marso 15, 2026398 araw
Marso 15, 2026 hanggang Marso 14, 2027200 araw
Marso 15, 2027 hanggang Marso 14, 2029100 araw
Mula Marso 15, 202947 araw

Dahil maiikli ang buhay ng mga certificate, delikado ang mano-manong renewal, kaya tiyaking awtomatikong nagre-renew ang host o certificate tool mo. Tiyakin din na nagre-redirect sa HTTPS ang plain HTTP:

curl -sI http://example.com/ | grep -i -E "^HTTP|^location"

Ang hinahanap mo ay isang 301 (o 308) na response na may location header na nagsisimula sa https://.

Aling mga security header ang dapat ipadala ng isang online store?

Hinaharang ng iilang response header ang mga karaniwang atake sa panig ng browser, nang halos walang gastos.

HeaderAno ang ginagawa nitoKaraniwang valueSource
Strict-Transport-SecuritySinasabihan ang mga browser na HTTPS lang ang gamitin, at pinipigilan ang mga user na i-click palampas ang mga certificate errormax-age=31536000; includeSubDomainsMDN (magbubukas sa bagong tab)
Content-Security-Policy: frame-ancestorsKinokontrol kung aling mga site ang puwedeng mag-embed ng mga page mo, na nagtatanggol laban sa clickjackingframe-ancestors 'self'MDN (magbubukas sa bagong tab)
X-Frame-OptionsMas lumang kontrol sa framing; ayon sa OWASP, pinalitan na ito ng frame-ancestors sa mga browser na sumusuporta ritoDENY o SAMEORIGINOWASP (magbubukas sa bagong tab)
X-Content-Type-OptionsPinipigilan ang MIME sniffing at hinaharang ang mga script at stylesheet na ipinadala na mali ang typenosniffMDN (magbubukas sa bagong tab)
Referrer-PolicyNililimitahan kung gaano karami sa mga URL mo ang ipinapadala sa ibang sitestrict-origin-when-cross-originOWASP
X-XSS-ProtectionHeader para sa XSS filter ng browser; ayon sa OWASP, puwede itong lumikha ng mga XSS vulnerability sa mga site na kung hindi dahil dito ay ligtasHuwag itakda, o 0OWASP

Tingnan kung ano ang ipinapadala ng store mo:

curl -sI https://example.com/

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Dalawang paalala. Hinaharang ng includeSubDomains ang anumang subdomain na gumagana lang sa HTTP, kaya suriin muna ang mga subdomain. Kailangan ng HSTS preloading ang max-age na hindi bababa sa 31536000 at ang includeSubDomains, kaya idagdag lang ang preload kapag handa na sa HTTPS ang bawat subdomain. Sulit magkaroon ng buong CSP na naglilimita sa mga script, pero ayon sa OWASP, komplikado itong i-configure at panatilihin, at kailangan itong i-test nang mabuti ng mga store na maraming app.

Dapat dala ng mga session at cart cookie ang tatlong attribute na ito, at makikita mo sila sa mga Set-Cookie response header.

AttributeEpekto (ayon sa MDN (magbubukas sa bagong tab))Saan ito mahalaga
SecureIpinapadala lang sa HTTPS; hindi ito maitatakda ng mga site na nasa plain HTTPBawat cookie sa isang HTTPS na store
HttpOnlyHindi ito mababasa ng JavaScript sa pamamagitan ng document.cookie, na nakakatulong laban sa XSSMga login session at cart
SameSite=Lax o StrictNililimitahan kung kailan ipinapadala ang cookie sa mga cross-site requestMga session; bagay ang Strict sa mga authentication at cart cookie
SameSite=NoneIpinapadala sa mga cross-site request; dapat kasama ang SecureMga naka-embed na third-party feature lang na nangangailangan nito

Kapag walang nakatakdang SameSite attribute, itinuturing ng mga browser na Lax ang cookie. Hindi puwedeng HttpOnly ang mga cookie na kailangang basahin ng sarili mong mga script, kaya magpokus sa mga cookie na kumikilala sa naka-log in na customer o admin.

curl -sI https://example.com/ | grep -i "^set-cookie"

Ipinapakita rin ng mga developer tool ng browser ang parehong impormasyon, kasama ang mga cookie na itinatakda ng mga script pagkatapos mag-load ng page.

Paano mo mahahanap ang mixed content?

Ang mixed content ay anumang resource na nilo-load sa HTTP sa isang page na inihahatid sa HTTPS, at inililista ito ng browser console.

Hinahati ito ng MDN (magbubukas sa bagong tab) sa dalawang grupo. "Upgradable" ang mga larawan, audio at video: awtomatikong hinihingi ng mga browser ang mga ito sa HTTPS. "Blockable" naman ang mga script, stylesheet, iframe, font at fetch() request: hinaharang ito ng mga browser, kaya nasisira ang anumang umaasa sa mga ito. Hinaharang din ang mga na-upgrade na request sa isang IP address lang.

Para mahanap ito, buksan ang console sa mga pangunahing template mo (home, collection, product, cart) at hanapin ang http:// sa code ng theme mo, sa content ng mga page at sa mga setting ng app. Ayon sa help center ng Shopify, ang anumang page ng store na may asset na hindi inihahatid sa HTTPS ay itinuturing na hindi secure (magbubukas sa bagong tab), at inirerekomenda nitong i-host ang mga asset sa Shopify o ihatid ang mga ito sa HTTPS. Sa WooCommerce, suriin ang content ng mga lumang post at ang mga theme option kung tumakbo man dati ang site sa http://.

Paano mo makikita ang mga lumang JavaScript library na may kilalang CVE?

Ilista ang mga library na nilo-load ng bawat page, basahin ang mga bersiyon nila, at ikumpara ang mga ito sa National Vulnerability Database.

Magsimula sa jQuery. Sa browser console, ibinabalik ng $.fn.jquery ang bersiyong naka-load (jQuery API (magbubukas sa bagong tab)). Mga bersiyong dapat i-flag:

CVEMga apektadong bersiyonIsyuNVD score (v3.1)
CVE-2020-11022 (magbubukas sa bagong tab)1.12.0 hanggang bago ang 3.5.0Puwedeng magpatakbo ng code ang pagpasa ng hindi pinagkakatiwalaang HTML sa mga method gaya ng .html() o .append()6.1 Medium
CVE-2020-11023 (magbubukas sa bagong tab)1.0.3 hanggang bago ang 3.5.0Pareho, para sa HTML na may mga <option> element; nasa KEV catalog ng CISA mula Enero 23, 20256.1 Medium
CVE-2019-11358 (magbubukas sa bagong tab)Bago ang 3.4.0Prototype pollution sa pamamagitan ng jQuery.extend(true, ...)6.1 Medium

Parehong naayos sa jQuery 3.5.0 ang dalawang isyu mula 2020. Kapag vulnerable ang bersiyon, ibig sabihin ay naroon ang may depektong code; kung maaabuso ito o hindi ay nakadepende sa kung paano ipinapasa ng site ang data rito. Kasama na sa WordPress ang jQuery 3.5.1 mula version 5.6 (magbubukas sa bagong tab), kaya ang lumang jQuery sa isang WooCommerce store ay senyales ng lumang WordPress o ng theme o plugin na naglo-load ng sarili nitong kopya. Sa Shopify, suriin ang mga file ng theme mo at ang mga app na nag-i-inject ng mga script.

Ano ang security.txt at kailangan ba ito ng store mo?

Isa itong plain text file na nagsasabi sa mga security researcher kung paano mag-ulat sa iyo ng vulnerability.

Ayon sa RFC 9116 (magbubukas sa bagong tab) (Abril 2022, isang Informational RFC, kaya boluntaryo ang pagsunod dito), dapat ihatid ang file sa HTTPS sa /.well-known/security.txt bilang text/plain. Required ang Contact at Expires, at inirerekomenda ng RFC na wala pang isang taon mula ngayon ang petsa ng Expires.

Contact: mailto:security@example.com
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: en
Policy: https://example.com/security-policy

Sa WooCommerce, puwede mong ilagay ang file sa server mo. Sa isang hosted platform, alamin kung puwede kang mag-publish ng file sa path na iyon; kung hindi, nakakatulong pa rin ang malinaw na nakalagay na security contact sa contact page mo.

Paano pinoprotektahan ng DMARC ang store mo laban sa email spoofing?

Sa DMARC, puwede mong hilingin sa mga mailbox provider na i-quarantine o i-reject ang email na gumagamit ng domain mo sa From address nang hindi pumapasa sa naka-align na SPF o DKIM.

Nangongolekta lang ng mga report ang isang record na nasa p=none; hindi nito pinipigilan ang spoofed na email. Inaasahan ng mga customer na manggagaling sa domain mo ang mga order confirmation at password reset, kaya sulit harangin ang phishing message na nagpapakita ng eksaktong domain mo. Suriin ang policy mo gamit ang dig +short TXT _dmarc.example.com, at tingnan ang RFC 9989 (magbubukas sa bagong tab) para sa specification. Hindi saklaw ng DMARC ang mga kahawig na domain, kundi ang domain lang na nagpa-publish ng record.

Ano ang pinamamahalaan ng Shopify, at ano ang kontrolado mo sa WooCommerce?

Ang Shopify ang nagpapatakbo ng mga server sa likod ng mga storefront nito, samantalang sa isang self-hosted na WooCommerce store, ikaw at ang host mo ang bahala sa mga setting ng server.

CheckShopifyWooCommerce (self-hosted)
TLS certificateLibre para sa lahat ng domain na idinagdag sa Shopify (magbubukas sa bagong tab); puwedeng umabot nang hanggang 48 oras para sa mga third-party domainAng host mo o ang sarili mong setup
Redirect mula HTTP papuntang HTTPSPlatformMga setting ng web server, CDN o host
Mga security headerIpinapadala ng mga server ng ShopifyWeb server, CDN o isang plugin
Mga cookie flagItinatakda ng platform ang sariling mga cookie ng Shopify; sa iyo ang mga cookie ng app at themeWordPress core, mga plugin at server
Mixed content at mga JS libraryAng theme, content at mga app moAng theme, content at mga plugin mo
security.txt at DMARCAng domain at DNS moAng domain at DNS mo

Nang suriin namin ang ilang storefront na naka-host sa Shopify noong Oktubre 2026, kasama sa mga response nila ang HSTS na may max-age na mga 91 araw, ang X-Content-Type-Options: nosniff at isang CSP na may upgrade-insecure-requests, habang magkakaiba ang frame-ancestors sa bawat store. Ayon sa Shopify, ito ay certified Level 1 PCI DSS compliant (magbubukas sa bagong tab). Ikaw pa rin ang responsable sa theme mo at sa mga naka-install na app.

Sa WooCommerce, sinasabi ng hardening guide (magbubukas sa bagong tab) ng WordPress na panatilihing updated ang WordPress at mga plugin, burahin ang mga plugin na hindi mo ginagamit, at tanungin ang host mo kung anong mga security precaution ang ginagawa nila.

Bakit hindi ito penetration test?

Aktibong sinusubukan ng penetration test ang mga atake; nagmamasid lang ang mga passive check.

Itinatakda ng NIST SP 800-115 ang penetration testing bilang security testing kung saan ginagaya ng mga evaluator ang mga totoong atake para makahanap ng paraan para malampasan ang mga security feature ng isang system (NIST glossary (magbubukas sa bagong tab)). Hindi nakikita ng mga passive check ang mga server-side na depekto sa mga plugin, mahihina o paulit-ulit na ginagamit na admin password, kawalan ng two-factor authentication, sirang access control o vulnerable na code na hindi kailanman lumalabas sa page source. Gamitin ang mga ito bilang baseline na puwede mong ulitin anumang oras. Para sa mas malalim na katiyakan, magpagawa ng penetration test na may nakasulat na saklaw, sa mga system na pagmamay-ari mo o may pahintulot kang i-test.

Nagpapatakbo ang isang libreng scan ng unang pagsusuri sa store mo. Saklaw ng Ulat sa Seguridad ng Website ang mga passive check sa artikulong ito, mula TLS at mga redirect hanggang sa mga header, cookie, mixed content, lumang library, security.txt at DMARC, kasama ang mga ayos para sa bawat natuklasan. Gaya ng anumang passive na pagsusuri, hindi nito magagarantiyang secure ang isang store.

Mga madalas itanong

Nalalagay ba sa panganib ang store ko dahil sa mga passive security check?

Hindi hihigit sa isang karaniwang pagbisita. Hinihingi nila ang parehong mga pampublikong page at DNS record na hihingin ng anumang browser o mail server, at hindi sila sumusubok mag-log in o magpadala ng attack payload.

Puwede ba akong magdagdag ng mga security header sa Shopify?

Galing sa mga server ng Shopify ang mga response header ng storefront, kaya makipag-ugnayan sa Shopify Support kung may kulang na header na kailangan mo. Puwedeng magdagdag ng ilang directive ang isang CSP <meta> tag sa theme mo, pero ayon sa MDN, hindi sinusuportahan ang frame-ancestors sa <meta>.

Kapag luma ang bersiyon ng jQuery, ibig sabihin ba ay na-hack na ang store ko?

Hindi. Ibig sabihin nito ay may naka-load na code na may mga kilalang vulnerability, na nagpapataas ng panganib kung nagpapasa ang site ng hindi pinagkakatiwalaang HTML sa mga apektadong method. I-update ito, o alisin ang theme o plugin na naglo-load nito.

Gaano katagal puwedeng maging valid ang isang TLS certificate ngayon?

Ang mga publicly trusted na certificate na inisyu mula Marso 15, 2026 ay puwedeng maging valid nang hanggang 200 araw lang. Bababa ang limit sa 100 araw mula Marso 15, 2027 at sa 47 araw mula Marso 15, 2029.

Required ba ang security.txt file?

Isang Informational RFC ang RFC 9116, kaya boluntaryo ang pag-publish ng file ayon sa standard. Mura itong i-publish at nagbibigay ito sa mga researcher ng malinaw na paraan para makontak ka.

Kapag malinis ang resulta ng passive scan, secure na ba ang store ko?

Hindi. Ipinapakita lang nito na mukhang tama ang pampublikong configuration. Kailangan ng ibang testing para sa mga server-side vulnerability, seguridad ng account at mga depekto sa business logic.

Mga sanggunian

Lahat ng gabay